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10 年 前 ， 没 人 能 预见 互联 网 的 发 展会 给 关系 型 数 
据 库 带 来 如 此 多 的 挑战 。 在 此 期 间 ， 我 杀身 经 历 























了 在 快速 发 展 的 大 型 


程 。 开 始 时 只 








1 有 很 少 




















互联 网 公司 应 用 MySQL 的 过 
的 数据 ， 一 台 服 务 器 就 可 以 











了 。 然 后 就 得 建立 备份 ， 以 便 应 对 大 量 的 读 取 和 








不 时 的 宕 机 。 


层 ， 调 整 所 有 的 查询 ， 投 入 更 多 的 硬件 。 
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多 长 时 间 ， 就 得 加 一 个 缓存 
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后 ， 你 会 发 现 自 : 
上 ， 并 重新 构建 大 量 
分 。 之 后 不 久 ， 你 又 


























1 需要 将 数据 切 分 到 多 个 集群 























数据 库 结构 限制 住 了 。 





的 应 用 逻辑 以 适应 这 种 切 
会 发 现 被 自己 数 月 前 设计 的 









































怎么 会 呢 ? 这 是 因为 现在 集群 中 的 数据 太 多 ， 需 
























































很 长 时 间 ， 也 需要 DBA 投 入 
。 在 代码 中 处 理 要 简单 一 些 ， 




















队 数 月 的 努力 。 最 后 ， 你 会 
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没有 在 核心 数据 库 服务 器 中 内 置 更 多 此 类 功能 


为 了 应 对 现在 Web 应 用 的 数据 膨胀 ， 开 源 社区 像 
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的 “好 方法 "。 从 内 存 中 的 键 





SQL 的 MySQLInnoDB 变 种 等 


复杂 方法 ， 无 所 不 有 。 但 





选择 反而 更 难 了 。 






























































选择 多 了 ， 做 出 正确 的 
我 自己 就 研究 过 其 中 很 多 种 。 


MongoDB 的 实用 性 着 实 令 人 着 迷 。MongoDB 并 不 





去 迎合 所 有 人 的 全 部 需求 。 它 








间 取 得 了 很 好 的 平 





复杂 的 任务 。 也 就 是 说 ， 它 具 备 文 撑 今 天 主流 


在 功能 和 复杂 性 之 


F 衡 ， 并 且 大 大 简化 了 原先 十 分 





Web 应 用 的 关键 功能 ， 索引、 


的 查询 语法 ， 特别 灵活 











不 牺牲 速度 。 





秉持 MongoDB 自 身 的 风格 ， 








a MongoDB 新 用 户 通 过 
能 入 门 ， 而 有 经 验 的 用 户 则 





的 数据 模型 。 
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本 书简 洁 明 快 、 通 俗 
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理 主题 ， 如 复种 小 
考 。 
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户 端 API 和 高 级 的 管 


阅读 第 1 章 ， 马 上 就 
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备份 和 分 片 ， 本 书 都 是 权威 参 








根据 我 最 近 每 天 使 用 














MongoDB 的 经 验 ， 我 相信 本 


书 会 始终 不 离 我 左右 ， 从 最 初 安装 到 进行 分 片 或 








备份 式 集群 的 产 上 
手 。 





本 重要 的 参考 书 。 
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前 言 
本 书 的 组 织 结构 


本 书 分 为 六 个 部 分 ， 涵 盖 了 开发 、 管 理 以 及 部 署 
的 方方面面 。 























2 MongoDB 











第 1 章 将 简要 讲述 MongoDB 的 背景 : 项 目 创立 原 
习 ， 和 希望 达到 的 目标 ， 选 用 它 的 理由 。 第 2 章 接 
着 介绍 一 些 MongoDB 的 核心 概念 和 术语 ， 还 有 如 
可 上 手 操作 数据 库 和 shell 的 相关 内 容 。 接 下 来 两 
章 介绍 MongoDB 开 发 者 需要 掌握 的 基础 知识 。 第 
3 章 展 示 如 何 执行 基本 的 写 入 操作 ， 包 括 在 不 同 
安全 和 速度 等 级 下 的 实现 细节 。 第 4 章 主要 介绍 
如 何 查 找 文 档 和 创建 复杂 的 查询 。 这 一 章 还 包括 
如 何 和 迭代 结果 集 和 其 他 一 些 用 于 处 理 结果 集 的 方 
法 ， 比 如 限制 结果 集 的 数量 ， 略 过 一 些 结果 ， 以 
及 对 结果 集 排序 。 





















































































































































































































































使 用 MongoDB 进 行 开发 


第 5 章 将 介绍 什么 是 索引 以 及 如 何 为 MongoDB 的 
集合 建立 索引 。 第 6 章 说 明 如 何 使 用 各 种 特殊 类 





























值 、 文 档 分 
分 的 最 后 一 











型 的 索引 和 集合 。 第 7 章 展 示 了 一 些 利用 

















组 、 聚 合 框架 和 MapReduce。 这 一 间 











章 会 介绍 如 何 设 计 应 用 程序 : 第 8 于 


























讲述 如 何 更 


复制 


























好 地 在 应 用 程序 中 使 用 MongoDB。 

















建立 一 个 




















章 涵盖 了 与 

















了 副本 集 与 
度 介 绍 副本 





























集 的 运行 。 








分 片 


第 13 章 开始 





快速 地 在 本 地 








以 及 设置 。 






































第 9 章 开 始 介绍 复制 ， 着 重 讲述 如 何 快速 在 本 地 

副本 集 ， 还 会 介绍 一 些 可 用 选项 。 第 10 
副本 集 相 关 的 一 
应 用 程序 的 交互 。 第 12 章 从 管理 的 角 




















些 概念 。 第 11 章 展示 












































介绍 分 片 ， 并 通过 一 个 例子 展示 如 何 
进行 分 片 。 第 14 章 介绍 集群 的 组 成 











第 15 章 介绍 如 个 



































应 用 程序 管理 





























Be POR PAS 








从 应 用 程序 的 





9 度 介 绍 MongoDB 管 理 




















为 不 同 的 应 用 程序 选 





择 合适 的 片 键 。 最 后 ， 第 16 章 介绍 分 片 集群 的 管 
理 


























的 很 多 方面 。 | 
进行 的 操作 。 第 18 章 介绍 一 些 管理 任务 ， 比 如 创 
ERI 移动 和 压缩 数据 . 第 19 章 介绍 MongoDB 
的 持久 数据 存储 。 


服务 器 管理 


最 后 一 部 分 集中 介绍 服务 器 管理 。 第 20 章 将 给 
启动 和 终止 MongoDB 时 的 一 些 通用 选项 。 第 21 
讨论 在 监控 数据 库 运行 时 如 何 查 看 监控 信息 。 第 
22 章 介绍 在 不 同类 型 的 部 署 中 如 何 备份 和 恢复 数 
H. 最 后 ， 第 23 章 将 介绍 部 署 MongoDB 时 需要 
牢记 于 心 的 一 些 条 统 设置 。 


附录 


附录 A 介 绍 了 MongoDB 的 版 本 控制 方案 ， 以 及 在 
Windows. OS X 和 Linux 上 的 安装 细节 。 附 录 B 详 
细 说 明了 MongoDB 的 内 部 工作 原理 : 存储 引擎 、 
数据 格式 和 传输 协议 。 






























































































































































本 书 排版 规范 

本 书 使 用 的 排版 规范 如 下 所 示 。 

。 楷 体 用 于 表示 新 的 术语 。 

。 等 宽 字 体 表示 程序 片段 ， 也 在 段落 中 表示 程 
序 中 使 用 的 变量 、 函 数 名 、 命 令 行 实 用 工 
E., HATE, EAJ 和 关键 字 等 元 素 。 


。 等 宽 斜 体 用 户 需 要 根据 自己 提供 的 值 或 由 上 
下 文 确定 的 值 进行 更 改 的 部 分 。 
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a], “这 个 图 标 代表 小 窗 门 、 建 议 或 者 兴 
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个 标识 代表 警告 。 








使 用 代码 示例 


让 本 书 助 你 一 臂 之 力 。 也 许 你 要 在 自己 的 程序 或 
文档 中 用 到 本 书 中 的 代码 。 除 非 大 段 大 段 地 使 

]， 否 则 不 必 与 我 们 联系 取得 授权 。 例 如 ， 无 需 
请 求 许可 ， 就 可 以 用 本 书 中 的 几 段 代码 写成 一 个 
程序 。 日 是 销售 或 者 发 布 OReilly 图 书 中 代码 的 光 
盘 则 必须 事先 获得 授权 。 引 用 书 中 的 代码 来 回答 
问题 也 无 需 授 权 。 将 大 段 的 示例 代码 整合 到 你 自 
己 的 产品 文档 中 则 必须 经 过 许可 。 


我 们 非常 感谢 你 能 标明 出 处 ， 但 并 不 强求 。 出 处 
一 般 包括 书 名 、 作 者 、 出 版 商 和 ISBN， 例 如 
《MongoDB 权 威 指南 (第 2 版 )》，Kristina 
Chodorow # (O'Reilly, 2013) 。 版 权 所 有 ， 
978-1-449-34468-9。 


如 果 有 关于 使 用 代码 的 未 尽 事宜 ， 可 以 随时 与 我 
们 联系 : permissions@oreilly.com. 
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Safari 在 线 图 书 








Safari 在 线 图 书 (www.safaribooksonline.com) 是 
同时 以 图 书 和 视频 的 











应 需 而 变 的 数字 图 书馆 。 它 











形式 出 版 世界 顶级 技术 和 商务 作家 上 


Safari Books Online 是 技术 专家 、 软 伯 
、 商 务 人 士 和 创意 人 士 开 





Web 设计 师 
决 问题 、 学 习 和 认证 培训 的 























第 一 手 资 











的 专业 作品 。 


F 开 发 人 员 、 
展 调研 、 解 
资料 。 








对 于 组 织 团体 、 政 府 机 构 和 个 人 ，Safari Books 














Online 提供 各 种 产品 组 合 和 灵活 的 定价 策略 。 用 
户 可 通过 一 个 功能 完备 的 数据 库 检索 系统 访问 















































O'Reilly Media. Prentice Hall Professional, 
Addison-Wesley Professional, Microsoft Press, 
Sams, Que. Peachpit Press. Focal Press. Cisco 
Press. John Wiley & Sons, Syngress. Morgan 
Kaufmann, IBM Redbooks. Packt. Adobe Press, 
FT Press. Apress. Manning, New Riders, 
McGraw-Hill. Jones & Bartlett. Course 





Technology 以 及 其 他 几 十 家 
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F 千 种 图 








书 、 培 训 视 频 和 正式 出 版 之 前 的 书稿 。 要 了 解 
SafariBooks Online 的 更 多 信息 ， 我 们 网 上 见 。 








联系 我 们 


请 把 对 本 
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的 评论 和 问题 发 给 出 版 社 。 


O'Reilly Media, Inc. 1005 Gravenstein Highway 
North Sebastopol, CA 95472 
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北京 市 西城 
室 (100035) 
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奥 莱 利 技术 咨询 〈 北 京 ) 有 限 公司 








O'Reilly 的 每 一 Ae Ter DL 你 可 以 在 那儿 
找到 关于 本 书 的 相关 信息 











码 以 及 大 








他 的 信息 。 
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http://oreil.ly/mongodb-2e 





对 于 本 书 的 评论 和 技术 性 问题 ， 请 发 送 电 子 邮 件 


到 : 


的 网 站 地 址 是 : 























bookquestions@oreilly.com 


要 了 解 更 多 O’Reilly 图 








书 、 培 训 课 程 、 会 议和 新 





闻 的 信息 ， 请 访问 以 下 网 站 ; 


http://www.oreilly.com 

我 们 在 Facebook 的 地 址 如 下 : 
http://facebook.com/oreilly 

请 关注 我 们 的 Twitter 动态 : 
http://twitter.com/oreillymedia 
我 们 的 YouTube 视频 地 址 如 下 : 


http://www.youtube.com/oreillymedia 
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第 l 章 ”MongoDB 简 介 








MongoDB 是 一 款 强 大 、 灵 活 ， 

















型 数据 库 。 它 能 扩展 出 非常 多 上 
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aus HERE. RE Cageregation) ， 以 及 地 理 
空间 索引 ( ali index) 。 




















易于 扩展 的 通用 
的 功能 ， 如 二 级 索 


范围 查询 (range 








MongoDB 的 主要 设计 特点 。 





1.1 易于 使 用 




















本 章 涵盖 了 


MongoDB 是 一 个 面向 文档 (document-oriented) 





的 数据 库 ， 而 不 是 关系 型 数据 库 。 
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象 语言 的 开发 者 对 数据 的 看 法 一 致 。 

















另外 ， 不 再 有 预定 义 模式 (predefined 
schema) : 文档 的 键 (key) 和 值 (value) 不 再 
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于 开发 者 能 名 进行 快速 关 代 ， 所 以 开发 进程 得 以 
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1 全 是 一 个 小 规模 的 应 用 
得 惊人 ， 甚 至 超出 了 很 多 数据 库 的 处 
罕见 的 T 级 别 数据 ， 现 在 已 是 











程序 ， 需 要 存储 的 数据 
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个 困难 : 应 该 如 何 扩展 数据 库 ? 实质 上 ， 这 是 缚 
向 扩展 (scale up) 和 横向 扩展 (scale out) 之 间 





的 选择 。 
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强 的 机 器 了 。 男 一 个 选择 是 横向 扩展 要 增加 存 




















储 空间 或 提高 性 能 ， 只 需 购买 一 台 普 通 的 服务 器 


并 把 它 添加 到 集群 中 就 
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服务 器 ，MongoDB 就 会 自动 将 现 有 数据 向 新 
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MongoDB 作 为 一 款 通 用 型 数据 库 ， 除 了 能 够 创 
建 、 读 取 、 hn 还 提供 一 系列 
不 断 扩 展 的 独特 功能 
。 索 引 (indexing) 
MongoDB 文 持 通 用 二 级 索引 ， 人 允许 多 种 快速 
间 索 引 ， 以 及 全 文 索引 。 





0 K 


& Caggregation) 


Mongo DBX F RAE” (aggregation 
pipeline) 。 用 户 能 通过 简单 的 片段 创建 复杂 
的 聚合 ， 并 通过 数据 库 自 动 优化 。 


。 特殊 的 集合 类 型 


MongoDB 文 持 存 在 时 间 有 限 的 集合 ， 适 用 于 
那些 将 在 某 个 时 刻 过 期 的 数据 ， 如 会 话 

(session) 。 类 似 地 ，MongoDB 也 支持 固定 
大 小 的 集合 ， 用 于 保存 近期 数据 ， 如 日 志 。 


e 文件 存储 (file storage) 


MongoDB 文 持 一 种 非常 易 用 的 协议 ， 用 于 存 
储 大 文件 和 文件 元 数据 。 


MongoDB 并 不 具备 一 些 在 关系 型 数据 库 中 和 
的 功能 ， 如 连接 Goin) 和 复杂 的 多 行事 
(multirow transaction) 。 省 略 这 些 功能 是 出 于 架 
构 上 的 考虑 (为 了 得 到 更 好 的 扩展 性 ) ， 因 为 在 
分 布 式 系统 中 这 两 个 功能 难以 高 效 地 实现 。 


1.4 卓越 的 性 能 


MongoDB 的 一 个 主要 目标 是 提供 卓越 的 性 能 ， 这 
很 大 程度 上 决定 了 MongoDB 的 设计 。MongoDB 能 
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对 文档 进行 动态 填充 (dynamic padding) ， 也 能 
预 分 配 数据 文件 以 利用 额外 的 空间 来 换取 稳定 的 






































性 能 。MongoDB 把 尽 可 能 多 的 内 存 





























引 。 总 之 ，MongoDB 在 各 方面 的 设 
它 的 高 性 能 。 


虽然 ，MongoDB 非 常 强大 并 试图 保留 


















































MERTE 








(cache )， 试 图 为 每 次 查询 自动 选择 正确 的 索 





计 都 旨 在 保持 








姑 关 系 型 数据 














库 的 很 多 特性 ， 但 它 并 不 追求 具备 
的 所 有 功能 。 只 要 有 可 能 ， 数 据 库 
处 理 和 逻辑 交 给 客户 端 (通过 驱动 
应 用 程序 代码 来 实现 ) 。 这 种 精简 
























































关系 型 数据 库 
服务 器 就 会 将 
程序 或 用 户 的 
方式 的 设计 是 














MongoDB 能 够 实现 如 此 高 性 能 的 原 








于 之 二 ss 





1.5 小 结 





本 书 将 详细 说 明 MongoDB 开 发 过 程 中 的 一 些 特定 














设计 背后 的 原因 和 动机 ， 借 此 分 享 MongoDB 背 后 
的 哲学 。 当 然 ， 掌 握 MongoDB 最 好 的 方式 是 创建 



































一 个 易 扩 展 、 灵 活 、 快 速 的 功能 完 
储 ， 这 也 是 MongoDB 的 意义 所 在 。 











备 的 数据 存 


2% MongoDB AETH ATIR 





MongoDB4E 党 强 大 但 
些 MongoDB 的 基本 概念 。 








。 文 档 是 MongoDB 中 数 
4 数据 库 


似 于 关系 型 
表现 力 。 
。 类 似 地 ， 



































大 入 




















集合 (collection) F 














和 
。 MongoDB 的 一 





的 数据 库 (database) , 
的 集合 。 
。 每 一 个 文档 都 有 一 个 特殊 的 键 ”_ 
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Li 


AA 





键 在 文档 所 





有 动态 模式 (dynamic schema) 的 表 。 
有 多 个 相互 独立 
每 一 个 数 ] 











个 实例 可 以 











很 容易 上 手 。 


的 基本 单元 ， 
里 系统 中 的 行 ， 
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本 章 会 介绍 








可 以 看 作 是 一 个 














据 库 都 拥 





id", 这 个 


属 的 集合 中 是 唯一 的 。 




















2.1 文档 


ongoDB 自 带 了 
JavaScript shell, FJ} 
例 或 数据 操作 。 


个 简单 但 








功能 强大 的 
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里 MongoDB 的 实 





文档 是 MongoDB 的 核心 概念 。 文 档 就 是 键 值 对 的 




















个 有 序 集 。 


每 种 编程 语言 表示 文档 的 方法 








一 样 ， 





但 大 多 数 编程 语 
构 ， 比 如 映射 Cmap) ~ 











散 列 


吾 言 都 有 一 些 相 通 的 数 # 
Chash) 或 字 


不 大 
居 结 


























MA 


(dictionary) 。 例 如 ， 在 JavaScript 里 面 ， 文 档 
被 表示 为 对 象 : 


{"greeting" : "Hello, world!"} 





















































这 个 文档 只 有 一 个 键 "greeting"， 其 对 应 的 值 
为 "Hello，wor1d!"。 大 多 数 文档 会 比 这 个 简单 
的 例子 复杂 得 多 ， 通 常会 包含 多 个 键 / 值 对 : 


{"greeting" : "Hello, world!", "foo" : 3} 



































从 上 面 的 例子 可 以 看 出 ， 文 档 中 的 值 可 以 是 多 种 
不 同 的 数据 类 型 (甚至 可 以 是 一 个 完整 的 内 髓 文 
档 ， 详 见 2.6.4 节 ) 。 在 这 个 例子 

中 ，"greeting" 的 值 是 一 个 字符 串 ， 而 "foo" 的 
值 是 一 个 整数 。 


文档 的 键 是 字符 串 。 除 了 少数 例外 情况 ， 键 可 以 
使 用 任意 UTF-8 字 符 。 
























































。 键 不 能 含有 \0《〈 空 字符 ) 。 这 个 字符 用 于 表 
示 键 的 结尾 。 
。 .和 $ 具 有 特殊 意义 ， 只 能 在 特定 环境 下 使 用 
《后 面 的 章节 会 详细 说 明 ) 。 通 常 ， 这 两 个 
字符 是 被 保留 的 ， 如 果 使 用 不 当 的 话 ， 驱 动 
程序 会 有 提示 。 

















































































































MongoDB 不 但 区 分 类 型 ， 而 且 区 分 大 小 写 。 例 











如 ， 下 面 的 两 个 文档 是 不 同 的 : 





























{"foo" : 3} 

{"foo" : "3"} 

下 面 两 个 文档 也 是 不 同 的 : 
{"foo" : 3} 

{"Foo" : 3} 














还 有 一 个 非常 重要 的 事项 需要 注意 ，MongoDB 的 








文档 不 能 有 重复 的 键 。 例 如 ， 下 面 的 文档 是 非法 








的 ， 





























{"greeting" 


"Hello, world!", "greeting" 


























文档 中 的 键 / 值 对 是 有 序 的 : {"x”: 1, "y": 


2} & {"y": 2, 


"x": 1) 是 不 同 的 。 通 常 ， 字 














段 顺序 并 不 重要 ， 无 须 让 数据 库 模 式 依赖 特定 的 
字段 顺序 (MongoDB 会 对 字段 重新 排序 )。 在 某 


些 特殊 情况 下 




















就 此 给 出 提 Re 








一 些 编程 语言 对 文档 的 默认 表示 根本 就 不 包含 顺 
序 问 题 Cun: Python 中 的 字典 、Perl 和 Ruby 1.8 中 
的 散 列 ) 。 通 常 ， 
































字段 顺序 变 得 非常 重要 ， 本 书 将 









































这 些 语 言 a 的 驱动 具有 某 些 特殊 





的 机 制 ， 可 以 在 必要 时 指定 文档 


2.2 集合 








的 顺序 











集合 就 是 一 组 文档 。 如 果 将 MongoDB 中 的 一 个 文 





档 比 喻 为 关系 型 数 # 
就 相当 于 一 张 表 。 








MI 


2.2.1 





JSA 














集合 是 动态 模式 的 。 
档 可 以 是 各 式 各 样 
存储 在 同一 个 集合 里 面 : 


的 。 











中 库 中 的 一 行 ， 那 么 一 个 集合 

















这 意味 着 
例如 ， 下 





















































{"greeting" 
{"foo" : 5} 





"Hello, world! "} 





需要 注意 的 是 ， 上 面 




















(一 个 是 字符 
全 不 同 。 因 为 
而 来 的 一 个 问 
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合 里 
是 : 


cae 由 





的 文档 不 光 
个 是 整数 ) 
面 可 以 放置 











值 的 类 型 不 同 
， 它 们 的 键 
王 何 文档 4 ’ 























还 有 必要 使 | 


这 的 确 值 得 思考 ; 既然 没有 必要 





档 的 模式 ， 为 什么 还 要 使 用 











儿 个 重要 的 原因 。 











。 如 果 把 各 利 




















h 各 样 的 文档 不 加 区 


多 个 集合 呢 ? 





EBRE 


SEZER 





用 多 个 集合 


NA 


Ness 
































iv 


分 地 放 在 同一 























个 集合 里 ， 无 论 对 开发 者 还 是 对 管理 员 
都 将 是 点 梦 。 开 发 者 要 么 确保 每 次 查询 
可 特定 类 型 的 文档 ， 要 么 让 执行 查询 的 应 用 
程序 来 处 理 所 有 不 同类 型 的 文档 。 如 果 查 询 
博客 文章 时 还 要 剔除 含有 作者 数据 的 文档 ， 
这 会 带 来 很 大 困扰 。 


在 一 个 集合 里 查询 特定 类 型 的 文档 在 速度 上 
也 很 不 划算 ， 分 开 碍 询 多 个 集合 要 快 得 多 。 
例如 ， 假 设 集合 里 面 一 个 名 为 "type" 的 字段 
用 于 指明 文档 是 skim、whole 还 是 chunky 
monkey。 那 么 ， 如 果 从 一 个 集合 中 查询 这 三 
种 类 型 的 文档 ， 速 度 会 很 慢 。 但 如 果 将 这 三 
种 不 同类 型 的 文档 拆 分 为 三 个 不 同 的 集合 ， 
每 次 只 需要 查询 相应 的 集合 ， 速 度 快 得 多 。 


把 同 种 类 型 的 文档 放 在 一 个 集合 里 ， 数 据 会 
更 加 集中 。 从 一 个 只 包含 博客 文章 的 集合 里 
查询 几 篇 文章 ， 或 者 从 同时 包含 文章 数据 和 
作者 数据 的 集合 里 查 出 几 篇 文章， 相 比 之 
下 ， 前 者 需要 的 磁盘 寻 道 操作 更 少 。 


创建 索引 时 ， 需 要 使 用 文档 的 附加 结构 〈 特 
别 是 创建 唯一 索引 时 ) 。 索 引 是 按照 集合 来 
定义 的 。 在 一 个 集合 中 只 放 入 一 种 类 型 的 文 
档 ， 可 以 更 有 效 地 对 集合 进行 索引 。 
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F 面 这 些 重 a 因 促使 我 们 创建 一 个 模式 ， 把 相 
关 类 型 的 文档 组 织 在 一 起 ， 尽 管 MongoDB 对 此 并 


没有 强制 要 求 。 





























2.2.2 ”命名 




















集合 使 用 名 称 进 行 标识 。 集 合 名 可 以 是 满足 下 列 
条 件 的 任意 UTF-8 字 符 串 。 











。 集 合 名 不 能 是 空 字符 串 〈"") 。 

。 集合 名 不 能 包含 字符 《〈 空 字符 ) ， 这 个 字 

符 表 示 集 合 名 的 结束 。 

。 集 合 名 不 能 以 “system.” 开 头 ， 这 是 为 系统 
合 保 留 的 前 级 。 例 如 ，system.users 这 个 集合 
保存 着 数据 库 的 用 户 信息 ， 而 
system.namespaces 集 合 保存 着 所 有 数据 库 集 
合 的 信息 。 

j 户 创建 的 集合 不 能 在 集合 名 中 包含 保留 字 

符 '$% 。 因 为 某 些 系 统 生 成 的 集合 中 包含 $， 

很 多 驱动 程序 确实 支持 在 集合 名 里 包含 该 字 

符 。 除 非 你 要 访问 这 种 系统 创建 的 集合 ， 否 

则 不 应 该 在 集合 名 中 包含 $。 


子 集合 
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组 织 集合 的 一 种 惯例 是 使 用 “.” 分 隔 不 同 命名 空 zi 
































的 子 集合 。 例 如 ， 








个 具有 博客 功能 的 应 用 可 能 











包含 两 个 集合 ， 分 别 是 blog.posts 和 blog.authors。 
这 是 为 了 使 组 织 结 构 更 清晰 ， 这 里 的 blog 集 合 








(这 个 集合 甚至 不 需 
任何 关系 。 








看 要 存在 ) 跟 它 的 子 集 合 没有 








虽然 子 集合 没有 任何 特别 的 属性 ， 但 : 
有 用 ， 因 而 很 多 MongoDB 工 具 都 使 用 了 子 集合 



























































e GridFS 〈 一 种 ) 














j 于 存储 大 文件 的 协议 ) 使 用 























细 介 绍 GridFS 。 





子 集合 来 存储 文件 的 元 数据 ， 这 样 就 可 以 与 
文件 内 容 块 很 好 地 隔离 开 来 。 (第 6 章 会 详 




















) 

















shell 中 ，db .bl1 











大 多 数 驱动 程序 都 提供 了 一 些 语法 糖 ， 用 于 
访问 指定 集合 的 子 集合 。 例 如 ， 在 数据 库 




















og 代表 blog 和 集合 ， 


而 db .blog.posts 代 表 blog.posts 集 合 。 





在 MongoDB 中 ， 使 月 
效 ， 值 得 推荐 。 


2.3 ”数据库 





日 子 集合 来 组 织 数据 非常 高 


在 MongoDB 中 ， 多 个 文档 组 成 集合 ， 而 多 个 集合 
可 以 组 成 数据 库 。 一 个 MongoDB 实 例 可 以 承载 多 














个 数据 库 ， 每 个 数据 库 拥 有 0 个 或 者 多 个 集合 。 

每 个 数据 库 都 有 独立 的 权限 ， 即 便 是 在 磁盘 上 ， 
不 同 的 数据 库 也 放置 在 不 同 的 文件 中 。 按 照 经 

验 ， 我 们 将 有 关 一 个 应 用 程序 的 所 有 数据 都 存储 
在 同一 个 数据 库 中 。 要 想 在 同一 个 MongoDB 服 务 
器 上 存放 多 个 应 用 程序 或 者 用 户 的 数据 ， 就 需要 
使 用 不 同 的 数据 库 。 


数据 库 通 过 名 称 来 标识 ， 这 点 与 集合 类 似 。 数 据 
库 名 可 以 是 满足 以 下 条 件 的 任意 UTF-85 


。 不 能 是 空 字 符 串 CM) 。 

。 KERR). \ a NOR SN A S 
(一 个 空格 ) 、 \0 ( 空 字符 ) 。 基本 上 ， 只 
能 使 用 ASCIH 中 的 字母 和 数字 。 

。 数 据 库 名 区 分 大 小 写 ， 即 便 是 在 不 区 分 大 小 
写 的 文件 系统 中 也 是 如 此 。 简 单 起 见 ， 数 据 
库 名 应 全 部 小 写 。 

o 数据 库 名 最 多 为 64 字 节 


要 记 住 一 点 ， 数 据 库 最 终 会 变 成 文件 系统 里 的 文 
牛 ， 而 数据 库 名 就 是 相应 的 文件 名 ， 这 是 数据 库 
名 有 如 此 多 限制 的 原因 。 


另外 ， 有 一 些 数据 库 名 是 保留 的 ， 可 以 直接 访问 
这 些 有 特殊 语义 的 数据 库 。 这 些 数据 库 如 下 所 


































































































































































































































































































ZI o 
e admin 


MA brill 











E 的 角度 来 讲 ， 这 是 “roof 数据 库 。 





果 将 一 个 用 户 添加 到 admin 数 # 
自动 获得 所 有 数据 库 的 权限 。 








服务 器 端 命令 也 只 能 从 admin 数 据 库 运行 ， 








出 所 有 数据 库 或 关闭 服务 器 。 


e local 



































这 个 数据 库 永远 都 不 可 以 复制 ， 且 一 
器 上 的 所 有 本 地 集合 都 可 以 存储 在 这 个 数据 
(第 9 章 











库 中 。 
库 。) 


e config 








会 详细 介 


oA ti 


如 

BÆ, 这 个 用 户 将 
再 者 ， 一 些 特 定 的 
如 列 

AIRS 














| 及 本 地 数据 








MongoDB H 
分 片 信息 会 














于 分 片 设置 时 (参见 第 13 章 ) , 











把 数据 库 名 添加 
定名 ， 即 命名 空 











F 

















要 使 ) 
的 命名 空 





= 








存储 在 config 数 据 库 中 。 
集合 名 前 ， 得 到 集合 的 完全 限 


x 间 (namespace) 。 
jcms 数 据 库 中 的 blog.posts 集 合 ， 
x 间 就 是 cms.blog.posts。 























例如 ， 如 
这 个 集合 
命名 空间 的 


3 











长 度 不 得 超过 121 字 节 ， 且 在 实际 使 用 中 应 小 于 





100 字 节 。 “参考 附录 B， 了 解 MongoDB 中 集合 的 
命名 空间 及 内 部 表示 的 更 多 信息 。) 











2.4 启动 MongoDB 

















通常 ，MongoDB 作 为 网 络 服务 器 来 运行 ， 客 户 端 
可 连接 到 该 服务 器 并 执行 操作 。 下 载 

MongoDB (http://www.mongodb.org/downloads ) 

并 解压 ， 运 行 nongod 命 令 ， 启 动 数据 库 服 务 器 : 














$ mongod 

mongod --help for help and startup options 

Thu Oct 11 12:36:48 [initandlisten] MongoD 
dbpath=/data/db/ 64-bit host=spock 

Thu Oct 11 12:36:48 [initandlisten] db ver 

Thu Oct 11 12:36:48 [initandlisten] git ve 
3aaea5262d761eebb6bfef5351cfbfca7afe6e 

Thu Oct 11 12:36:48 [initandlisten] build 
Version 11.2.0: Tue Aug 9 20:54:00 PDT 
root: xnu-1699.24.8~1/RELEASE X86 64 x8 

Thu Oct 11 12:36:48 [initandlisten] option 

Thu Oct 11 12:36:48 [initandlisten] journa 

Thu Oct 11 12:36:48 [initandlisten] recove 
recovery needed 

Thu Oct 11 12:36:48 [websvr] admin web con 
port 28017 

Thu Oct 11 12:36:48 [initandlisten] waitin 











在 Windows 系 统 中 ， 执 行 这 个 命令 : 








$ mongod.exe 





Va 





附录 A。 


ms 
关于 安装 MongoDB 的 详细 信息 ， 人 参见 








mongod 在 没有 参数 的 情况 下 会 使 用 默认 数据 目 





录 /data/db (Windows 系 统 中 为 C:\data\db) > WR 
































数据 目录 不 存在 或 者 不 可 写 ， 服 务 器 会 启动 失 
败 。 因 此 ， 在 启动 MongoDB 前 ， 先 创建 数据 目录 
(如 mkdir -p /data/db / ) ， 以 确保 对 该 目录 有 和 写 
权限 ， 这 点 非常 重要 。 




















不 


> 














启动 时 ， 服 务 器 会 打印 版 本 和 系统 信息 ， 然 后 等 























竺 连接。 默认 情况 下 ，MongoDB 监 听 27017 端 























mongod 还 会 














。 如 果 端 口 被 占用 ， 启 动 将 失败 。 通 常 ， 这 是 
由 F 已 经 有 一 个 MongoDB 实 例 在 运行 了 。 











会 启动 一 个 非常 基本 的 HTTP 服务器 ， 








监听 数字 比 主 端口 号 高 1000 的 端口 ， 也 就 是 


28017 端 口 。 








这 意味 着 ， 通 过 浏览 器 访问 





http://localhost28017， 能 获取 数据 库 的 管理 信 


























中 按 下 Ctrl-C。 


Va 
k 











细节 ~ 参见 第 20 音 o 


2.5 MongoDB shel 简 介 


MongoDB 自 带 JavaScript shell， 可 在 shell' 
令 行 与 MongoDB 实 例 交 互 。shell 非 常 有 用 


























已 可 以 执行 管理 操作 ， 检 查 运 行 实例 ， 
他 尝试 。 对 MongoDB 来 说 ，mongo shel 








中 止 mongod 的 运行 ， 只 须 在 运行 着 服务 器 的 shell 


> 
要 想 了 解 启 动 和 停止 MongoDB 的 更 多 




















使 
， 通 

亦 或 做 
] 是 至 关 重 


PE POKA 




















= 








ZEEE 








至 上 





要 的 工具 ， 其 应 用 之 广泛 将 体现 在 本 
部 分 中 。 











2.5.1 运行 shell 


运行 nongo 启 动 shell: 








$ mongo 
MongoDB shell version: 2.4.6 


connecting to: test 
> 











启动 时 ，shell 将 自动 连接 MongoDB 服 务 器 ， 须 确 
保 mongod 已 启动 。 























shell 是 一 个 功能 完备 的 JavaScript 解 释 器 ， 可 运行 
任意 JavaScript 程 序 。 为 说 明 这 一 点 ， 我 们 运行 几 
个 简单 的 数学 运算 : 














> x = 200 
200 

> X / 5; 
40 














另外 ， 可 充分 利用 JavaScript 的 标准 库 : 


> Math.sin(Math.PI / 2); 

1 

> new Date("2010/1/1"); 

"Fri Jan 01 2010 00:00:00 GMT-@50@ (EST)" 
> "Hello, World!".replace("World", "MongoD 
Hello, MongoDB! 















































再 者 ， 可 定义 和 调用 JavaScript 函 数 : 

















> function factorial (n) { 
. if (n <= 1) return 1; 


. return n * factorial(n - 1); 


> factorial(5); 
120 








需要 注意 ， 可 使 用 多 行 命令 。shell 会 检测 输入 的 
JavaScript 语 句 是 否 完整 ， 如 没 写 完 可 在 下 一 行 接 
着 号。 在 某 行 连续 三 次 按 下 回 车 键 可 取消 未 输入 
完成 的 命令 ， 并 退回 到 > 一 提示 符 。 
































2.5.2 ”MongoDB 客 户 端 


能 运行 任意 JavaScript 程 序 听 上 去 很 酷 ， 不 过 shell 
的 真正 强大 之 处 在 于 ， 它 是 一 个 独立 的 MongoDB 
客户 端 。 启 动 时 ，shell 会 连 到 MongoDB 服 务 器 的 
test 数 据 库 ， 并 将 数据 库 连 接 赋值 给 全 局 变量 
db。 这 个 变量 是 通过 shell 访 问 MongoDB 的 主要 入 


wo 


如 果 想 要 查看 db 当前 指向 哪个 数据 库 ， 可 以 使 


jdb 命 令 : 























































































































> db 
test 























为 了 方便 习惯 使 用 SQL shell MAA, shellik 





一 些 非 JavaScript 语 法 的 
额外 的 功能 ， 而 是 一 些 非常 棒 的 语法 糖 。 例 如 ， 


最 重要 的 操作 之 一 为 选择 数据 库 : 














“ 展 。 这 些 扩展 并 不 提供 























> use foobar 
switched to db foobar 

















现在 , 如 
数据 库 : 




















果 查 看 db 变量 ， 会 发 现 其 正 指向 foobar 


> db 
foobar 

















会 将 此 变量 





打印 出 来 。 
































通过 db 变量 ， 可 访问 其 ! 








忆 为 这 是 一 个 JavaScript shell， 所 以 键入 一 个 变量 
量 的 值 转换 为 字符 串 











《 即 数据 库 名 ) 并 








的 集合 。 例 如 ， 通 过 
































db.baz 可 返回 当前 数据 库 的 baz 集 合 。 因为 通过 



























































shell 可 访问 集合 ， 这 意味 着 ， 几 乎 所 有 数据 库 操 
作 都 可 以 通 

2.5.3 ”shell 中 的 基本 操作 

在 shell 中 查看 或 操作 数据 会 用 到 4 个 基本 操作 : 
创建 、 读 取 、 更 新 和 删除 〈 即 通常 所 说 的 CRUD 








H. 


操作 ) 。 


1. 创建 


insert 函 数 可 将 一 个 文档 添加 到 集合 中 。 举 一 个 
存储 博客 文章 的 例子 。 首 先 ， 创 建 一 个 名 为 post 
的 局 部 变量 ， E 用 于 表示 
我 们 的 文档 。 它 会 有 几 个 

键 : "title", a (发 布 日 
HA) o 
























































> aa = { title : "My Blog Post" 
... "content" : "Here's my blog post 
... "date" : new Date()} 
{ 
"title" : "My Blog Post", 
"content" : "Here's my blog post.", 
"date" : ISODate("2012-08-24T21:12:09. 
} 








这 个 对 象 是 个 有 效 的 MongoDB 文 档 ， 所 以 可 以 
jinsert 方 法 将 其 保存 到 blog 和 集合 中 : 


> db.blog.insert(post) 


这 篇 文章 已 被 存 到 数据 库 中 。 要 查看 它 可 用 调用 
集合 的 find 方 法 : 




























































































> db.blog.find() 
{ 
"_id" : ObjectId("5037ee4a1084eb3ffeef 
"title" : "My Blog Post", 
"content" : "Here's my blog post.", 
"date" : ISODate("2012-08-24T21:12:09. 
} 








可 以 看 到 ， 我 们 曾 输入 的 键 / 值 对 都 已 被 完整 地 记 
录 。 此 外 ， 还 有 一 个 额外 添加 的 
BE" id"。"”_ id" 突然 出 现 的 原因 将 在 本 章 末 尾 
解释 。 





























2. 读 取 


find 和 findone 方 法 可 以 用 于 查询 集合 里 的 文 
档 。 若 只 想 查 看 一 个 文档 ， 可 用 findone: 





















































> db.blog.findone() 
{ 
"_id" : ObjectId("5037ee4a1084eb3ffeef 
"title" : "My Blog Post", 
"content" : "Here's my blog post.", 
"date" : ISODate("2012-08-24T21:12:09. 
} 








find 和 findone 可 以 接受 一 个 查询 文档 作为 限定 

















条 件 。 这 样 就 可 以 查询 符合 一 定 条 件 的 文档 。 使 









































jfind 时 ，shell 会 自动 显示 最 多 20 个 匹配 的 文 








档 ， 也 可 获取 更 多 文档 。 第 4 章 会 详细 介绍 查询 


相关 的 内 容 。 
3. 更 新 








使 用 update 修 改 博客 文章 。 


update 接 受 (至 





>) 两 个 参数 ， 第 一 个 是 限定 条 件 (用 于 匹配 待 
个 是 新 的 文档 。 假 设 我 们 要 


更 新 的 文档 ) ， 第 二 个 























为 先前 写 的 文章 增加 评论 功能 ， 就 需要 增加 一 个 








新 的 键 ， 用 于 保存 评 计 / 























仑 数组 。 


f 先 ， 修 改变 量 post， 增 加 " 








comments" 键 : 





post.comments = 


> 
[] 


然后 执行 update 操 作 ， 
为 “My Blog Post” 的 文章 














[] 




















草 : 


新 版 本 的 文档 蔡 换 标题 








> db.blog.update({title : 


"My Blog Post"}, 





























现在 ， 文 档 已 经 有 了 "comments" 键 。 再 用 find 











查看 一 下 ， 可 以 看 到 











新 的 键 : 








|> db.blog.find() 











{ 
"id" : ObjectId("5037ee4a1084eb3ffeef 
"title" : "My Blog Post", 
"content" : "Here's my blog post.", 
"date" : ISODate("2012-08-24T21:12:09. 
"comments" : [ J 

} 

4. 删除 








使 用 remove 方 法 可 将 文档 从 数据 库 中 永久 删除 。 
如 果 没 有 使 用 任何 参数 ， 它 会 将 集合 内 的 所 有 文 
档 全 部 删除 。 它 可 以 接受 一 个 作为 限定 条 件 的 文 
档 作 为 参数 。 例 如 ， 下 面 的 命令 会 删除 刚刚 创建 
的 文章 : 

































































> db.blog.remove({title : "My Blog Post"}) 








现在 ， 集 合 又 是 空 的 了 。 
2.6 ”数据 类 型 


本 章 开 始 部 分 介绍 了 文档 的 基本 概念 ， 现 在 你 已 
经 会 启动 、 运 行 MongoDB， 也 会 在 shell 中 进行 一 
些 操作 了 。 这 一 节 的 内 容 会 更 加 深入 。MongoDB 
文 持 将 多 种 数据 类 型 作为 文档 中 的 值 ， 下 面 将 一 















































2.6.1 基本 数据 类 型 


在 概念 上 ，MongoDB 的 文档 








相近 ， 攻 











示 方 式 : 





官网 证 明了 这 点 ) ， 且 仪 包含 6 种 数据 类 
样 有 很 多 好 处 : 易于 理解 
忆 。 然 而 ， 从 另 一 方 四 
FRE, BAA 
的 表达 能 





型 ， 所 以 JSON 


虽然 JSON 具 备 的 这 些 类 型 已 





而 可 VATE RIT ISON. 
JSON (Chttp://www.json.org) 是 Pif 


— 





其 规范 仅 用 











一 段 文字 就 能 描 











5JavaScript! 


























的 对 象 
的 数据 表 


清楚 (其 












































Zi 







































































卓绝 大 多 
都 还 需要 











数 应 用 (万 














其 是 在 与 数 和 
要 其 他 一 些 重要 的 类 型 。 




















日 期 类 型 


另外 ，JSON 


和 整数 ， 





， 这 使 原本 容易 的 
只 有 一 种 数字 类 型 ， 无 法 区 分 浮 点 数 
更 别 说 区 分 32 位 和 64 位 数字 了 。 {I} 


























日 期 处 理 








irate 
来 说 ， 因为 只 有 null、 布 


数据 类 


AD 


ol 交道 时 ) 
| 如 ，JSON 没 有 
变 得 烦人 。 









































者 ， 





JSON 无 法 表示 其 他 一 些 通用 类 型 ， 如 正则 表达 式 


或 函数 。 


MongoDB 在 保留 





上 ， 添 加 


























JSON 基 本 键 / 值 对 特 | 性 
了 其 他 一 些 数据 类 











型 





的 基础 
同 的 编程 语 








言 下 ， 这 些 类 型 的 确切 表示 有 些许 差异 。 下 面 说 
明 MongoDB 支 持 的 其 他 通用 类 型 ， 以 及 如 何在 文 
档 中 使 用 它们 。 













































































e null 
nul1 用 于 表示 空 值 或 者 不 存在 的 字段 ; 
("x" : null} 

。 布尔 型 
布尔 类 型 有 两 个 值 true 和 false: 








{"x" : true} 


。 数 值 
shell 默 认 使 用 64 位 浮 点 型 数值 。 因 此 ， 以 下 
数值 在 shell 中 是 很 “正常 ”的 : 






































{"x" : 3.14} 
或 : 
{"x" : 3} 

















对 于 整 型 值 ， 可 使 用 NumberInt 类 (表示 4 
字 节 带 符号 整数 ) 或 NumberLong 类 (表示 8 











字符 带 符号 整数 ) ， 分 别 举例 如 下 : 




















{"x" : NumberInt("3")} 
{"x" : NumberLong("3")} 
i ee 























{"x" : "foobar"} 




















期 
期 被 存储 为 自 新 纪元 以 来 经 过 的 毫秒 数 ， 
不 存储 时 区 : 





















































{"x" : new Date()} 











正则 表达 式 
查询 时 ， 使 用 正则 表达 式 作为 限定 条 件 ， 语 
法 也 与 JavaScript 的 正则 表达 式 语 法 相同 : 



































{"x" : /foobar/i} 








数组 


























数据 列表 或 数据 集 可 以 表示 为 数组 : 

















文档 可 稀 套 其 他 文档 ， 被 嵌 套 的 文档 作为 父 
文档 的 值 ; 

















{"x" : {"foo" : "bar"}} 








e XJ Rid 
对 象 id 是 一 个 12 字 节 的 ID， 是 文档 的 唯一 标 
识 。 详 见 2.6.5 节 。 











{"x" : ObjectId()} 



































还 有 一 些 不 那么 常用 ， 但 可 能 有 需要 的 类 型 ， 包 
括 下 面 这 些 。 
































。 二 进 制 数 据 
二 进 制 数据 是 一 个 任意 字 节 的 字符 串 。 它 不 
能 直接 在 shell 中 使 用 。 如 果 要 将 非 UTF-8 字 
符 保存 到 数据 库 中 ， 二 进 制 数 据 是 唯一 的 方 










































































A, 





。 代码 
查询 和 文档 中 可 以 包括 任意 JavaScript 代 码 : 














{"x" : function() { /* ... */ }} 





















































另外 ， 有 几 种 大 多 数 情况 下 仅 在 内 部 使 用 《或 被 
其 他 类 型 取代 ) 的 类 型 。 在 本 书 中 ， 出 现 这 种 情 
况 时 会 特别 说 明 。 











a a 息 ， 参 考 附 录 


2.6.2 日 期 





在 JavaScript 中 ，Date 类 











期 类 





日 






































关于 
的 参数 格式 ， 





JavaScript 


(constructor) 作 
的 方式 ) ， 返 回 的 是 
HH (Date) WR. 
JavaScript J 
点 ， 没 有 始终 使 用 
到 一 堆 混 乱 的 
及 查询 等 几乎 所 有 操作 时 


期 类 的 完整 解释 








H 











H 


期 对 象 时 ， 应 
Date (C...) ， 而 非 Date ©...) o 


使 ) 
h 





可 以 用 作 Mo 











= 
ip 





ongoDB 的 


Jnew 


生 构 造 函 数 











为 函数 进行 调用 











日 其 

















日 期 (Dat 





ey Ar g 


MFK 





E 























期 对 象 和 日 








期 的 字符 串 。 








无 法 匹配 ， 所 以 执行 删除 、 
致 很 多 问题 。 


， 以 及 构造 函数 

















AB 
aw 








( 即 不 包括 new 
= 表示 , ma E 
这 个 结果 与 MongoDB 无 关 ， 
[ 作 机 制 决 定 的 。 














参见 ECMAScript 规 范 15.9 节 
Chttp://www.ecmascript.org) 。 


shell 根 据 本 地 时 





区 设置 显示 日 





期 对 象 。 然 而 ， 数 





据 库 中 存储 的 
未 存储 对 应 的 时 








区 。 





为 男 一 个 键 的 值 〉。 


2.6.3 ”数组 





数组 是 一 组 
栈 或 队列 ) ， 
操作 。 


在 下 
数组 : 




















值 ， 


看 的 文档 





日 期 仅 为 新 纪元 以 来 的 宫 秒 数 ， 并 
(当然 ， 可 将 时 








区 信息 存储 





它 既 能 作为 有 序 对 象 《 如 列表 、 





也 能 作为 无 序 对 象 〈 如 数据 集 ) 来 





AA, 





"things" 这 个 键 的 值 是 一 个 





{"things" 


: ["pie", 3.14]} 





此 例 
此 ， 


三 | 
KE 





表示 ， 数 组 可 包含 不 同 数据 关 到 
一 个 字符 串 和 一 个 浮 点 数 ) 。 








AYE TGR CE 
实际 





RL, %® 


规 的 键 / 值 对 支持 的 所 有 值 都 可 以 作为 数组 的 值 ， 








数组 
文档 


中 




















甚至 可 








能 “ 


其 











DBE 








e 


内 容 进 行 操作 。 这 样 就 能 使 月 
进行 查询 和 构建 索引 了 。 例 如 ， 之 前 的 例子 中 ， 
MongoDB 可 以 查询 
个 元 素 的 所 有 文档 。 








uy 
EL 











HE H, 
要 是 经 





"things" 数 组 中 


何 


























常 使 





就 是 MongoDB 
“深入 ”数组 内 部 对 
有 数组 内 容 对 数组 





包含 3.14 这 


j 这 个 查询 ， 可 











以 对 "things" 创 建 索引 来 提高 性 能 。 
MongoDB 可 以 使 用 原子 更 新 对 数组 内 容 进 行 修 
改 ， 比 如 深入 数组 内 部 将 pie 改 为 pi。 本 书后 面 还 
会 介绍 更 多 这 种 操作 的 例子 。 




















2.6.4 WRX 








文档 可 以 作为 键 的 值 ， 这 样 的 文档 就 是 内 嵌 
档 。 使 用 内 散文 档 ， 可 以 使 数据 组 织 方 式 更 加 自 
然 ， 不 用 非得 存 成 局 平 结构 的 键 / 值 对 。 


例如 ， 用 一 个 文档 来 表示 一 个 人 ， 同 时 还 要 保存 
他 的 地 址 ， 可 以 将 地 址 信息 保存 在 内 舰 
的 "address" 文档 中 : 





































































































{ 
"name" : "John Doe", 
"address" : { 
"street" : "123 Park Street", 
"city" : "Anytown", 
"state" : "NY" 
} 
} 




















上 面 例子 中 "address" 键 的 值 是 一 个 内 哈 文 档 ， 
这 个 文档 有 自己 



































的 " 
值 。 


构 ， 





Be AF 


street", 





并 能 “深入 ” 





，MongoDB 能 够 “到 
其 中 构建 索引 、 








稍 后 会 深入 讨论 模式 设 i 














子 也 可 以 看 得 出 内 翌 文 档 可 
这 个 例子 中 的 文档 一 般 
会 被 拆 分 成 两 个 表 中 的 两 个 行 
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MongoDB 这 样 
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以 改变 处 天 


"city" 和 "state" 键 以 及 对 应 的 
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在 MongoDB 
址 文档 嵌入 到 人 员 文 档 中 。 











话 ， 内 骨 文 档 会 使 信息 的 表示 方式 更 
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做 的 坏处 就 是 会 
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导致 更 多 的 数据 重 


复 。 假 设 “address” 是 关系 数据 库 中 的 一 个 独立 的 
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MongoDB 中 存储 的 文档 必须 有 一 个 "_id" 键 。 这 
H 
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只 能 有 一 个 文档 的 "_id" 值 为 123。 

















1. ObjectId 





ObjectId 是 ”id" 的 默认 类 型 。 它 设计 成 轻 量 型 





都 有 唯一 的 "_id"， 确 保 集合 里 面 每 个 文档 都 能 
被 唯一 标识 。 如 果 有 两 个 集合 的 话 ， 两 个 集合 可 
以 都 有 一 个 "id" 的 值 为 123， 但 是 每 个 集合 里 面 
























































地 生成 它 。 这 是 MongoDB 采 用 ob 
是 其 他 比较 常规 的 做 法 《比如 自 亏 
的 主要 原因 ， 因 为 在 多 个 服务 












































的 ， 不 同 的 机 器 都 能 用 全 局 唯一 的 同 种 方法 方便 
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z 














jectId， 而 不 
增加 的 主键 ) 
司 步 自动 增加 




















主键 值 既 费 力 又 费时 。 因 为 设计 MongoDB 的 初衷 
就 是 用 作 分 布 式 数据 库 ， 所 以 能 够 在 分 片 环境 中 
































生成 唯一 的 标示 符 非 常 重要 。 


ObjectId 使 用 12 字 节 的 存储 空间 ， 






































是 一 个 由 24 








个 干 六 进 制 数字 组 成 的 字符 串 〈 每 个 字 节 可 以 存 


























储 两 个 十 六 进 制 数字 ) 。 由 于 看 起 来 很 长 ， 不 少 
人 会 觉得 难以 处 理 。 但 关键 是 要 知道 这 个 长 长 的 
0bjectId 是 实际 存储 数据 的 两 倍 长 。 





















































如 果 快 速 连续 创建 多 个 0bjectId， 


会 发 现 每 次 











只 有 最 后 几 位 数字 有 变化 。 另 外 ， 中 间 的 几 位 数 
字 也 会 变化 (要 是 在 创建 的 过 程 中 停顿 几 秒 

钟 ) 。 这 是 0bjectId 的 创建 方式 导致 
的 。0bjectId 的 12 字 节 按 照 如 下 方式 生成 : 
































o|1|12|13|14|15|16|17|8|9|1 
WRR | 机 器 PID | 计数 


ObjectId 的 前 4 个 字 节 是 从 标准 纪元 开始 的 时 间 
惟 ， 单 位 为 秒 。 这 会 带 来 一 些 有 用 的 属性 。 


。 时 间 惟 ， 与 随后 的 5 字 节 〈 稍 后 介绍 ) AS 
起 来 ， 提供 了 秘 级 别 的 唯 -性 
。 由 于 时 间 惟 在 前 ， 这 意味 着 ObjectId 大 致 
会 按照 插入 的 顺序 排列 。 这 对 于 某 些 方面 很 
有 用 ， 比 如 可 以 将 其 作为 索引 提高 效率 ， 但 
是 这 个 是 没有 保证 的 ， 仅 仅 是 “大 致 "。 

。 这 4 字 节 也 隐 含 了 文档 创建 的 时 间 。 绝 大 多 
数 驱动 程序 都 会 提供 一 个 方法 ， 用 于 从 
ObjectId 获 取 这 些 信息 。 


寻 为 使 用 的 是 当前 时 间 ， 很 多 用 户 担 心 要 对 服务 
器 进行 时 钟 同步 。 虽 然 在 某 些 情况 下 ， 在 服务 器 
间 进 行 时 间 同 步 确实 是 个 好 主意 (参见 23.6.1 

节 ) ， 但 是 这 里 其 实 没 有 必要 ， 因 为 时 间 惟 的 实 
际 值 并 不 重要 ， 只 要 它 总 是 不 停 增加 就 好 了 【〔 每 










































































































































































































































































秒 一 次 ) 。 


接 下 来 的 3 字 节 是 所 在 主机 的 唯一 标识 符 。 通 常 
是 机 器 主机 名 的 散 列 值 Chash) 。 这 样 就 可 以 确 





保 不 同 主机 生成 不 同 的 ObjectId， 


Ke 








不 产生 冲 


为 了 确保 在 同一 台 机 器 上 并 发 的 多 个 进程 产生 的 
































0bjectId 是 唯一 的 ， 接 下 来 的 两 字 节 来 自 
生 0bjectId 的 进程 的 进程 标识 符 (PID) o 























in PE ela 生 








的 ObjectId 是 唯一 的 。 最 后 3 字 节 








加 的 计数 器 ， 确 保 相 同 进程 同一 秒 产 生 g 




















一 个 自动 增 








I — 











0bjectId 也 是 不 一 样 的。 一 秒 钟 最 多 允许 每 个 
进程 拥有 2$63 (16777216) 个 不 同 的 





ObjectId. 
2. 自动 生成 _id 
前 面 讲 到 ， 如 果 插 入 文档 时 没有 " 























_id' ' 键 ， 系统 


会 自动 帮 你 创建 一 个 。 可 以 由 MongoDB 服 务 器 来 
做 这 件 事 ， 但 通常 会 在 客户 端 由 驱动 程序 完成 。 












































这 一 做 法 非常 好 地 体现 了 MongoDB 的 哲学 : 能 交 
给 客户 端 驱动 程序 来 做 的 事情 就 不 要 交 
来 做 。 这 种 理念 背后 的 原因 是 ， 即 便 是 像 































































































MongoDB 这 样 扩展 性 非常 好 的 数据 库 ， 扩 展 应 用 
层 也 要 比 扩展 数据 库 层 容易 得 多 。 将 工作 交 由 客 
户 端 来 处 理 ， 就 减轻 了 数据 库 扩 展 的 负担 。 
















































































2.7 使 用 MongoDB Shell 


本 节 将 介绍 如 何 将 shell 作 为 命令 行 工具 的 一 部 分 
来 使 用 ， 如 何 对 shell 进 行 定制 ， 以 及 shell 的 一 些 
高 级 功能 。 


在 上 面 的 例子 中 ， 我 们 只 是 连接 到 了 一 个 本 地 的 
mongod 实 例 。 事 实 上， 可 以 将 shell 连 接 到 任何 
MongoDB 实 例 〈 只 要 你 的 计算 机 与 MongoDB 实 例 
所 在 的 计算 机 能 够 连通 ) 。 在 启动 shell 时 指定 机 
器 名 和 端口 ， 就 可 以 连接 到 一 台 不 同 的 机 器 〈 或 
者 端口 ) : 













































































$ mongo some-host:36666/myDB 
MongoDB shell version: 2.4.0 
connecting to: some-host:30000/myDB 
> 

















HI 


db J ZE WIE Il J some-host:30000_E myDBR4 





启动 mongo shell 时 不 连接 到 任何 mongod 有 时 很 方 














便 。 通 过 - -nodb 参 数 启动 shell， 启 动 时 就 不 会 连 
接任 何 数据 库 : 
$ mongo --nodb 


MongoDB shell version: 2.4.6 
> 



































启动 之 后 ， 在 需要 时 运行 hew 
Mongo(hostname) 命 令 就 可 以 连接 到 想 要 的 
mongod J : 











> conn = new Mongo("some-host : 30000" ) 
connection to some-host: 30000 

> db = conn.getDB("myDB" ) 

myDB 

















执行 完 这 些 命令 之 后 ， 就 可 以 像 平常 一 样 使 用 db 
了 。 任 何 时 候 都 可 以 使 用 这 些 命令 来 连接 到 不 同 
的 数据 库 或 者 服务 器 。 


























2.7.1 shell) ib Æ 














由 于 mongo 是 一 个 简化 的 JavaScript shell， 可 以 通 
过 查看 JavaScript 的 在 线 文 档 得 到 大 量 帮 助 。 ans 
MongoDB 特 有 的 功能 ，shell 内 置 了 帮助 文档 ， 可 
以 使 用 help 命 令 查看 : 
























































> help 
db.help() help on db metho 
db.mycoll.help() help on collecti 
sh.help() sharding helpers 


show dbs show database names 
show collections show collections in c 
show users show users in current datab 



































可 以 通过 db .help() 查 看 数据 库 级 别 的 帮助 ， 使 
jdb .foo.help() 查 看 集合 级 别 的 帮助 。 


如 果 想 知道 一 个 函数 是 做 什么 用 的 ， 可 以 直接 在 
shell 输 入 函数 名 (函数 名 后 不 要 输入 小 括号 )， 
这 样 就 可 以 看 到 相应 函数 的 JavaScript 实 现代 码 。 
例如 ， 如 果 想 知道 update 函 数 的 工作 机 制 ， 或 者 
是 记 不 清 参数 的 顺序 ， 就 可 以 像 下 面 这 样 做 : 


> db.foo.update 
function (query, obj, upsert, multi) { 
assert(query, "need a query"); 
assert(obj, "need an object"); 
this. validateObject(obj); 
this._mongo.update(this._fullName, que 
upsert ? true : fal 









































































































































2.7.2 ”使 用 shell 执 行 脚本 








本 书 其 他 章 都 是 以 交互 方式 使 用 shell， 但 是 也 可 
以 将 希望 执行 的 JavaScript 文 件 传 给 shell。 直 接 在 
命令 行 中 传递 脚本 就 可 以 了 : 






































$ mongo script1.js script2.js script3.js 
MongoDB shell version: 2.4.6 

connecting to: test 

I am scripti.js 

I am script2.js 

I am script3.js 


$ 











mongo shell 会 依次 执行 传 入 的 脚本 ， 然 后 退出 。 


如 果 希 望 使 用 指定 的 主机 /端口 上 的 mongod 运 行 
脚本 ， 需 要 先 指定 地 址 ， 然 后 再 跟 上 脚本 文件 的 
名 称 : 






























































$ mongo --quiet server-1:30000/foo script1 








这 样 可 以 将 db 指向 server-1:30000 上 的 foo 数 据 
库 ， 然 后 执行 这 三 个 脚本 。 如 上 所 示 ， 运 行 shell 
时 指定 的 命令 行 选 项 要 出 现在 地 址 之 前 。 

















可 以 在 脚本 中 使 用 print() 函 数 将 内 容 输出 到 标 
准 输出 (stdout) ， 如 上 下 的 脚本 所 示 。 这 样 就 可 
以 在 shell 中 使 用 管道 命令 。 Sn FEshel LBA 的 输 
出 管道 给 另 一 个 使 用 - -quiet 选 项 的 命令 ， 就 可 
以 让 shell 不 打印 “MongoDB shell version...” 提 示 。 


也 可 以 使 用 load() 函 数 ， 从 交互 式 shell 中 运行 脚 
本 : 










































































> load("script1.js") 
I am script1.js 
> 














在 脚本 中 可 以 访问 db 变量 ， 以 及 其 他 全 局 变量 。 
然而 ，shell 辅 助 函 数 〈 比 如 "use db" 和 "show 
collections") 不 可 以 在 文件 中 使 用 。 这 些 辅 
助 函数 都 有 对 应 的 JavaScript 函 数 ， 如 表 2-1 所 

ZB © 


表 2-1 shell 辅 助 函数 对 应 的 JavaScript 函 数 






























































辅助 函数 等 价 函 数 
use foo db.getSisterDB("foo") 
show dbs db .getMongo( ) .getDBs() 
show collections db.getCollectionNames() 














可 以 使 用 脚本 将 变量 注入 到 shell。 例 如 ， 可 以 在 
脚本 中 简单 地 初始 化 一 些 常用 的 辅助 函数 。 例 



























































































































































如 ， 下 面 的 脚本 对 于 本 书 的 复制 和 分 片 部 分 内 容 
非常 有 用 。 这 个 脚本 定义 了 一 个 connectTo() 函 
数 ， 它 连接 到 指定 庙 处 的 一 个 本 地 数据 库 ， 并 
且 将 db 指向 这 个 连接 。 
// defineConnectTo.js 
/** 
* 连接 到 指定 的 数据 库 ， 并 且 将 db 指向 这 个 连接 
var connectTo = function(port, dbname) { 
if (!port) { 
port = 27017; 
} 
if (!dbname) { 
dbname = "test"; 
} 
db = connect("localhost:"+port+"/"+dbn 
return db; 
}; 
如 果 在 shell 中 加 载 这 个 脚本 ，connectTo 函 数 就 
可 以 使 用 了 。 























> typeof connectTo 

undefined 

> load('defineConnectTo.js') 
> typeof connectTo 

function 





























除了 添加 辅助 函数 ， 还 可 以 使 用 脚本 将 通用 的 任 
务 和 管理 活动 自动 化 。 


默认 情况 下 ，shell 会 在 运行 shell 时 所 处 的 目录 
查找 脚本 可 以 使 用 run("pwd" ) 命 令 查 看 ) 。 
如 果 脚 本 不 在 当前 目录 中 ， 可 以 为 shell 指 定 一 个 
相对 路 径 或 者 绝对 路 径 。 例 如 ， 如 果 脚 本 放置 在 
~/my-scripts 目 录 中 ， 可 以 使 
Jload("/home/myUser/my- 
scripts/defineConnectTo. js") MS KIR 
defineConnectTo.js。 注 意 ，1load 函 数 无 法 解析 ~ 符 
TT o 


也 可 以 在 shell 中 使 用 run( ) 函 数 来 执行 命令 行 和 
序 。 可 以 在 函数 参数 列表 中 指定 程序 所 需 的 参 
数 : 


> run("Is", "-1", "/home/myUser/my-scripts 
sh70352| -rw-r--r-- 1 myUser myUser 2012-1 
sh70532| -rw-r--r-- 1 myUser myUser 2013-0 
sh70532| -rw-r--r-- 1 myUser myUser 2013-0 
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|sh70532| -rw-r--r-- 1 myUser myUser 2013-0] 





























通常 来 说 ， 这 种 使 用 方式 的 局 限 性 非常 大 ， 因 为 
输出 格式 很 奇怪 ， 而 且 不 支持 管道 。 





























2.7.3 ”创建 .mongorc.js 文 件 




















如 果 某 些 脚 本 会 被 频繁 加 载 ， 可 以 将 它们 添加 到 
mongorc.js 文 件 中 。 这 个 文件 会 在 启动 shell 时 自动 
运行 。 





例如 ， 我 们 希望 启动 成 功 时 让 shell 显 示 一 句 欢 迎 
语 。 为 此 ， 我 们 在 用 户 录 下 创建 一 个 名 
为 .mongorc.js 的 文件 ， 向 其 中 添加 如 下 内 容 ; 
























































// mongorc.js 


var compliment = ["attractive", "intellige 
var index = Math. floor(Math.random()*3) ; 


print("Hello, you're looking particularly 





然后 ， 当 启动 shell 时 ， 就 会 看 到 这 样 一 些 内 容 : 














$ mongo 
MongoDB shell version: 2.4.0- 
preconnecting to: test 








Hello, you're looking particularly like Ba 
































为 了 实用 ， 可 以 使 用 这 个 脚本 创建 一 些 自己 需要 
的 全 局 变量 ， 或 者 是 为 太 长 的 名 字 创 建 一 个 简短 
的 别名 ， 也 可 以 重 写 内 置 的 函数 。.mongorc.js 最 
见 的 用 途 之 一 是 移 除 那些 比较 “和 危险 ”的 shell 辅 助 
函数 。 可 以 在 这 里 集中 重 写 这 些 方法 ， 比 如 
l dag iat eh lard HB PR 
数 添 加 no 选项 ， 或 者 取消 它们 的 定义 。 


var no = function() { 
print("Not on my watch."); 

































































































































































}3 


// 禁止 删除 数据 库 
db.dropDatabase = DB.prototype.dropDatabas 


// 禁止 删除 集合 
DBCollection.prototype.drop = no; 






































// 禁止 删除 索引 
DBCollection.prototype.dropIndex = no; 


























改变 数据 库 函 数 时 ， 要 确保 同时 对 db 变量 和 DB 原 
型 进行 改变 (如 上 例 所 示 ) 。 如 果 只 改变 了 其 中 
—*, 那么 db 变量 可 和 铺 没有 改变 ， 或 者 这 些 改变 

































































在 新 使 用 的 所 有 数据 库 (运行 Use anotherDB 命 
令 ) 中 都 不 会 生效 。 


现在 ， 如 果 试 图 调用 这 些 函 数 ， 就 会 得 到 一 条 错 
误 















































误 提 示 。 注 意 ， 这 种 方式 并 不 能 保护 数据 库 免 受 
恶意 用 户 的 攻击 ， 只 能 预防 自己 的 手 误 。 


如 果 在 启动 shell 时 指定 --norc 参 数 ， 就 可 以 禁止 
力 


载 .mongorc.js。 




































































2.7.4 定制 shell 提 示 








将 prompt 变 量 设 为 一 个 字符 串 或 者 函数 ， 就 可 以 
重 写 默认 的 shell 提 示 。 例如 ， 如 果 正 在 运行 一 个 

需要 耗 时 几 分钟 的 查询 ， 你 可 能 希望 完成 时 在 
shell 提 示 中 输出 当前 时 间 ， 这 样 就 可 以 知道 最 后 
一 个 操作 的 完成 时 间 了 。 


prompt = function() { 
return (new Date())+"> 
































J: 
另 一 个 方便 的 提示 是 显示 当前 使 用 的 数据 库 : 












































prompt = function() { 
if (typeof db == 'undefined') { 
return '(nodb)> '; 








} 


// te Ba Wy 
try { 








居 库 操作 


db.runCommand({getLastError:1}); 


} 
catch (e) { 
print(e); 


return db+"> " 


3 





}3 











注意 ， 提 示 函 数 应 该 返 





字符 串 ， 而 且 应 该 小 心 











着 慎 地 处 理 异 常 ， 如 果 


户 造成 困惑 ! 
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示 中 出 现 了 异常 会 对 用 














通常 来 说 ， 提 示 函 数 中 应 该 包含 对 














getLastError 的 调用 。 
误 ， 而 且 可 以 在 shell 靳 7 
重启 了 mongod) 。 











这 样 可 以 捕获 数据 库 错 
于 时 自动 重新 连接 《比如 


























可 以 在 .mongorc.js 中 定 第 


H 


以 定制 多 个 提示 ， 在 shelld 





2.7.5 编辑 复合 变量 

















己 想 要 的 提示 。 也 可 
Ph 可 以 自由 切换 。 


jE 




















shell 的 多 行 支持 是 非常 有 限 的 ; 不 可 以 编辑 之 前 
的 行 。 如 果 编 辑 到 第 15 行 时 发 现 第 1 行 有 个 错 
误 ， 那 会 让 人 非常 愧 恼 。 因 此 ， 对 于 大 块 的 代码 
或 者 是 对 象 ， 你 可 能 更 愿意 在 编辑 器 中 编辑 。 为 
了 方便 地 调用 编辑 器 ， 可 以 在 shell 中 设置 EDITOR 
变量 〈 也 可 以 在 环境 变量 中 设置 ) : 

































































































































































> EDITOR="/usr/bin/emacs" 















































现在 ， 如 果 想 要 编辑 一 个 变量 ， 可 以 使 用 "edit 
变量 名 "这 个 命令 ， 比 如 : 








> var wap = db.books.findOne({title: "War 
> edit wap 














修改 完成 之 后 ， 保 存 并 退出 编辑 器 。 变 量 就 会 被 
重新 解析 然后 加 载 回 shell。 


在 .mongorc.js 文 件 中 添加 一 行内 容 ，EDITOR=" 编 
辑 器 路 径 "; ， 以 后 就 不 必 单 独 设置 EDITOR 变 量 
si 












































2.76 ”集合 命名 注意 事 


alin 


项 


























可 以 使 用 db .coLLectionName 获 取 一 个 集合 的 内 
容 ， 但 是 ， 如 果 集 合 名 称 中 包含 保留 字 或 者 无 效 

































































的 JavaScript 属 性 名 称 ，db .coLLectionName 就 
不 能 正常 作 So 

腿 设 要 访问 version 集 合 能 直接 使 

jdb .version， 因为 db_version 是 db 的 一 个 广 


法 (会 返回 当前 MongoDB 服 务 器 的 版 本 ): 














> db.version 
function () { 


return this.serverBuildInfo().version; 





} 








为 了 访问 version 集 合 ， 必 须 使 有 
函数 ， 





HgetCollection 





> db.getCollection("version" 





test.version 























如 果 集 合 名 称 中 包含 无 效 的 JavaScript 属 性 名 称 





(比如 foo-bar- | 


函数 来 访问 相应 的 集合 。《〈 注 意 ，JavaScript 必 性 





























也 可 以 使 用 这 个 














名 称 只 能 包含 字母 、 数 字 ， 以 及 "$" 和 "_" 字 符 ， 





而 且 不 能 以 数字 开头 。) 











还 有 一 种 方法 可 以 访问 以 无 效 属性 名 称 命名 的 引 


























合 ， 那 就 是 使 用 数组 访问 语法 : 














amt 


fÆ JavaScript 


中 ，x.y 等 同 于 x['y']。 也 就 是 说 ， 除 了 名 称 的 




















字面 量 之 外 ， 还 可 以 使 用 变量 访问 子 集合 。 
此 ， 如 果 需 要 对 blog 的 每 sip i covet 
可 以 使 用 如 下 方式 进行 迭代 : 















































var collections = ["posts", "comments", 

for (var i in collections) { 
print(db.blog[collections[i]]); 

} 





"a 





而 不 必 这 样 : 








print(db.blog.posts); 
print(db.blog.comments) ; 
print(db.blog.authors) ; 























注意 ， 不 能 使 用 db.blog.i， 这 样 会 被 解释 为 
test.blog.i， 而 不 是 test.blog.posts。 必 须 使 

































































jdb .blog[i] 语 法 才能 将 i 解释 为 相应 的 变量 。 
可 以 使 用 这 种 方式 来 访问 那些 名 字 怪 异 的 集合 : 





> var name = "@#&!" 
> db[name].find() 





















































使 用 db[name] 。 


直接 使 用 db .@#&! 进 行 查询 是 非法 的 ， 但 是 可 以 








第 3 章 ” 创 建 、 更 新 和 删除 文档 


本 章 会 介绍 对 数据 库 移 入 /移出 数据 的 基本 操作 ， 
具体 包含 如 下 操作 : 


。 癌 集合 添加 新 文档 ; 
。 从 集合 里 删除 文档 ; 
。 更 新 现 有 文档 ; 

。 为 这 些 操作 选择 合适 的 安全 级 别 和 速度 。 


3.1 插入 并 保存 文档 


插入 是 向 MongoDB 中 添加 数据 的 基本 方法 。 可 以 
使 用 insert 方 法 向 目标 集合 插入 一 个 文档 : 

































































> db.foo.insert({"bar" : "baz"}) 

















这 个 操作 会 给 文档 自动 增加 一 个 "_id" 键 (要 是 
原来 没有 的 话 ) ， 然 后 将 其 保存 到 MongoDB 中 。 
































3.1.1 批量 插入 



































如 果 要 向 集合 中 插入 多 个 文档 ， 使 用 批量 插入 会 
快 一 些 。 使 用 批量 插入 ， 可 以 将 一 组 文档 传递 给 
数据 库 。 










































































在 shell] 中 ， 可 以 使 用 batchInsert 函 数 实 现 批量 
插入 ， 它 与 Insert 函数 非常 像 ， 只 是 它 接受 的 是 
一 个 文档 数组 作为 参数 : 














> db.foo.batchInsert([{"_id" : ©}, {"_id" 
> db. rae find() 
{* : 8 } 
1.” 
1 














一 次 发 送 数 十 、 数 百 乃 至 数 干 个 文档 会 明显 提高 
插入 的 速度 。 


只 有 需要 将 多 个 文档 插入 到 一 个 集合 时 ， 这 种 方 
式 才 会 有 用 。 不 能 在 单 次 请 求 中 将 多 个 文档 批量 
插入 到 多 个 集合 中 。 要 是 只 导入 原始 数据 〈 例 
如 ， 从 数据 feed 或 者 MySQL 中 导入 ) ， 可 以 使 用 
命令 行 工具 ， 如 mongoimport， 而 不 是 批量 插 
入 。 男 一 方面 ， 可 以 使 用 批量 插入 在 将 数据 存 入 
MongoDB 之 前 对 数据 做 一 些小 的 修整 (将 日 期 转 
换 为 日 期 类 型 ， 或 添加 自 定义 的 "_id") ， 这 样 
批量 插入 也 可 用 于 导入 数据 。 


当前 版 本 的 MongoDB 能 接受 的 最 大 消息 长 度 是 48 
MB， 所 以 在 一 次 批量 插入 中 能 插入 的 文档 是 有 
限制 的 。 如 果 试 图 插入 48 MB 以 上 的 数据 ， 多 数 

































































































































































































































































驱动 程序 会 将 这 个 批量 插入 请 求 拆 分 为 多 个 48 
MB 的 批量 插入 请 求 。 具 体 可 以 查看 所 使 用 的 驱 
动 程序 的 相关 文档 。 


如 果 在 执行 批量 插入 的 过 程 中 有 一 个 文档 插入 失 
败 ， 那 么 在 这 个 文档 之 前 的 所 有 文档 都 会 成 功 插 
入 到 集合 中 ， 而 这 个 文档 以 及 之 后 的 所 有 文档 全 
部 插入 失败 



































































































































> db.foo.batchInsert([{"_id" : ©}, {"_id" 




















只 有 前 两 个 文档 会 被 插入 ， 因 为 插入 第 三 个 文档 
时 会 发 生 错 误 : 集合 中 已 经 存在 一 个 _id 为 1 的 文 
档 ， 不 能 重复 插入 。 


在 批量 插入 中 遇 到 错误 时 ， 如 果 希 

望 batchInsert 忽 略 错误 并 且 继 续 执 行 后 续 搬 
入 ， 可 以 使 用 continueOnError 选 项 。 这 样 就 可 
以 将 上 面 例子 中 的 第 一 个 、 第 二 个 以 及 第 四 个 文 
档 都 插入 到 集合 中 。Shell 并 不 支持 这 个 选项 ， 但 
是 所 有 了 驱动 程序 都 支持 。 






































































































































3.1.2 插入 校 验 




















插入 数据 时 ，MongoDB 只 对 数据 进行 最 基本 的 检 
查 : 检查 文档 的 基本 结构 ， 如 果 没 有 "” id" 字 






































段 ， 就 自动 增加 一 个 。 检 查 大 小 就 是 其 中 一 项 基 








本 结构 检查 : 所 有 文档 都 也 




















值 是 MongoDB 设 计 者 人 为 定 的 ， 未 来 有 可 能 会 增 
加 ) 。 作 这 样 的 限制 主要 是 为 了 防止 不 良 的 模式 














\ 须 小 于 16 MB (这 个 























设计 ， 并 且 保 证 性 能 一 致 。 

















如 果 要 查看 doc 文 档 


























的 BSON 大 小 (单位 为 字 节 











) 9 可 以 在 shell! 执 








行 Object.bsonsize(doc)。 





16 MB 的 数据 究竟 有 多 大 ? 
和 平 》 也 才 3.14 MB. 



































要 知道 整 部 《战争 与 


由 于 MongoDB 只 进行 最 基本 的 检查 ， 所 以 插入 非 


E 





























法 数据 很 容易 《如果 你 想 这 么 干 的 话 ) 。 因 此 ， 
应 该 只 允许 信任 的 源 ( 比 如 你 的 应 用 程序 服务 
器 ) 连接 数据 库 。 主 流 语言 的 所 有 驱动 程序 (以 


















































及 大 部 分 其 他 语言 的 驱动 程序 ) ， 都 会 在 将 数据 
piesa ery ea laa agi 



































使 用 不 可 识别 的 类 型 ) 。 
3.2 删除 文档 


是 否 过 大 ， 文 档 是 否 包含 非 UTF-8 字 符 串 ， 


现在 数据 库 中 有 些 数据 ， 要 删除 它 














> db.foo.remove() 











上 述 命令 会 删除 fpo 集 合 中 的 所 有 文档 。 但 是 不 会 
删除 集合 本 身 ， 也 不 会 删除 集合 的 元 信息 。 


remove 函 数 可 以 接受 一 个 查询 文档 作为 可 选 参 
数 。 给 定 这 个 参数 以 后 ， 只 有 符合 条 件 的 文档 才 
被 删除 。 例 如 ， 假 设 要 删除 mailing.list 集 合 中 所 
有 "opt-out" 为 true 的 人 : 
























































> db.mailing.list.remove({"opt-out" 








出 除 数据 是 永久 性 的 ， 不 能 撤销 ， 也 不 能 恢复 。 





出 除 速度 











川 除 文档 通常 很 快 ， 但 是 如 果 要 清空 整个 集合 
那么 使 jdrop Hi HAS EIR (然后 在 这 个 
空 集合 上 重建 各 项 索引 ) 。 


例如 ， 使 用 如 下 方法 插入 一 百 万 个 测试 数据 : 
> for (var i = ð; i < 1000000; i++) { 


. db.tester.insert({"foo": "bar", "baz": 


- } 































































































现在 把 刚 插 入 的 文档 都 删除 ， 并 记录 花费 的 时 
间 。 首 先 使 用 remove 进 行 删除 ; 









































> var timeRemoves = function() { 
. var start = (new Date()).getTime(); 


.. db.tester.remove(); 
. db.findOne(); // makes sure the remove 


. var timeDiff = (new Date()).getTime() 
. print("Remove took: "+timeDiff+"ms") ; 








> timeRemoves() 

















在 MacBookAir 笔 记 本 电脑 上 ， 这 段 脚 本 输 
出 “Removetook:9676ms”。 
































如 果 用 db .tester.drop() 人 代替 remove 和 
findone， 只 用 1 ms! 速度 提升 相当 明显 ， 但 也 
是 有 代价 的 : 不 能 指定 任何 限定 条 件 。 整 个 集合 
都 被 删除 了 ， 所 有 元 数据 也 都 不 见 了 。 


3.3 ”更 新 文档 


文档 存 入 数据 库 以 后 ， 就 可 以 使 A 
更 新 它 。update 有 两 个 参数 ， 是 查询 文档 ， 

于 定位 需要 更 新 的 目标 文档 ; OME 修改 器 
Cmodifier) 文档 ， 用 于 说 明 要 对 找到 的 文档 进 
行 哪 些 修改 。 















































































































































若是 两 个 更 新 同时 发 
先 到 达 服 务 器 的 先 执行 ， 接 着 执行 男 外 一 
。 所 以 ， 两 个 需要 同时 进行 的 更 新 会 迅速 接连 
FEI, LRRD SC ARISE RT 
得 “胜利 ”。 








7 FE 


















































3.3.1 文档 替换 














最 简单 的 更 新 就 是 用 一 个 新 文档 完全 替换 匹配 的 
文档 。 这 适用 于 进行 大 规模 模式 迁移 的 情况 。 例 
如 ， 要 对 下 面 的 用 户 文档 做 一 个 比较 大 的 调整 : 


{ 







































































"id" : ObjectId("4b2b9f67a1f631733d91 


"hame" : "joe", 
"friends" : 32, 
"enemies" : 2 








} 





我 们 希望 将 "friends" 和 "enemies" 两 个 字段 移 
到 "relationships" 子 文档 中 。 可 以 在 shell 中 改 



































变 文 档 的 结构 ， 然 后 使 用 update 蔡 换 数据 库 中 的 
当前 文档 : 






> var joe = db.users.findOne({"name" 
> joe.relationships = {"friends" : joe.fri 


{ 


"friends" 32, 
"enemies" : 2 
}> joe.username = 
"joe" 
> delete joe.friends; 
true 
> delete joe.enemies; 
true 
> delete joe.name; 
true 
> db.users.update({"name" : "joe"}, joe); 


joe.name; 




















现在 ， 用 findone 查 看 更 新 后 的 文档 结构 。 
{ 


























"_id" : ObjectId("4b2b9f67a1f631733d91 
"username" : "joe", 
"relationships" : { 

"friends" : 32, 

"enemies" : 2 














| 
> 
|a% 
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常见 的 错误 是 查询 条 件 匹 配 到 了 多 个 文档 ， 
然后 更 新 时 于 第 二 个 参数 的 存在 就 产生 重复 
nas 数据 库 会 抛 出 错误 ， 任 何 文档 都 不 
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例如 ， 有 好 几 个 文档 都 有 相同 的 "name" 值 ， 但 是 
我 们 没有 意识 到 : 



































> db.people.find() 

{"_id" : ObjectId("4b2b9f67a1f631733d917a7 
{"_id" : ObjectId("4b2b9f67a1f631733d917a7 
{"_id" : ObjectId("4b2b9f67a1f631733d917a7 


















































现在 如 果 第 二 个 Joe 过 生日 ， 要 增加 "age" 的 值 
我 们 可 能 会 这 么 做 : 





> joe = db.people.findOne({"name" : "joe", 


"Vid" : ObjectId("4b2b967a1f631733d91 
"name" : "joe", 
"age" : 20 
} : 
> joe.aget+; 
> db.people.update({"name" : "joe"}, joe); 
£11001 duplicate key on update 

















到 底 怎么 了 ? 调用 update 时 ， 数 据 库 会 查找 一 

个 "name" 值 为 "Joe" 的 文档 。 找 到 的 第 一 个 是 65 
岁 的 Joe。 然 后 数据 库 试 着 用 变量 joe 中 的 内 容 蔡 
换 找到 的 文档 ， 但 是 会 发 现 集 合 里 面 已 经 有 一 个 
具有 同样 " id" 的 文档 。 所 以 ， 更 新 就 会 失败 ， 基 
为 "id" 值 必须 唯一 。 为 了 避免 这 种 情况 ， 最 好 
































































































































确保 更 新 时 总 是 指定 一 个 唯 -文档 ， 例 如 使 























_id" 这 样 














的 键 来 匹配 。 对 于 上 面 的 例子 ， 这 








才 是 正确 的 更 新 方法 : 

















> db.people.update({"_id" : ObjectId("4b2b 

















使 用 ”id" 作 为 查询 条 件 比 使 用 随机 字段 速度 更 





























快 ， 因 为 是 通过 " id" 建立 的 索引 。 第 5$ 章 会 介绍 



































索引 对 更 新 和 其 他 操作 的 影响 。 








3.3.2 ”使 用 修改 器 




















通常 文档 只 会 有 一 部 分 要 更 新 。 可 以 使 用 原子 性 
的 更 新 修改 器 Cupdate modifier) ， 指 定 对 文档 









































中 的 某 些 字段 进行 更 新 。 更 新 修改 器 是 种 特殊 的 






































或 者 删除 键 ， 











键 ， 用 来 指定 复杂 的 更 新 操作 ， 比 如 修改 、 增 加 





还 可 能 是 操作 数组 或 者 内 髓 文档 。 





段 设 要 在 一 个 集合 中 放置 网 站 的 分 析 数 据 ， 只 要 











有 人 访问 页 
改 器 原子 性 ] 




















看 ， 就 增加 计数 器 。 可 以 使 用 更 新 修 

















地 完成 这 个 增加 。 每 个 URL 及 对 应 的 
访问 次 数 都 以 如 下 方式 存储 在 文档 中 : 











{ 
"id" 
“orl” 


: ObjectId("4b253b067525F35F94b6 


"www.example.com", 





"pageviews" : 52 

} 
每 次 有 人 访问 页 面 ， 就 通过 URL 找 到 该 页 面 ， 并 
j"$inc" 修 改 器 增加 "pageviews "的 值 。 





























> db.analytics.update({"url" : "www.exampl 
. {"$inc" : {"pageviews" : 1}}) 














现在 ， 执 行 一 个 find 操 作 ， 会 发 
见 "pageviews" 的 值 增加 了 1。 


> db.analytics.find() 
{ 














wH 





"_id" : ObjectId("4b253b067525f35f94b6 
"url" : "www.example.com", 
"pageviews" : 53 

















使 用 修改 费时 ，"_id" 的 值 不 能 改变 。 注意， 
整个 文档 蔡 换 时 可 以 改变 ”id"。) 其 他 键 值 ， 
包括 其 他 唯一 索引 的 键 ， 都 是 可 以 更 改 的 。 


1. "$set" 修 改 器 入 门 


"$set" 用 来 指定 一 个 字段 的 值 。 如 果 这 个 字段 不 
存在 ， 则 创建 它 。 这 对 更 新 模式 或 者 增加 用 户 定 






















































































义 的 键 来 说 非常 方便 。 例 如 ， 用 户 资 料 存储 在 下 
ACRE CRS E: 






























































> db.users.findOne() 
{ 
"Vid" : ObjectId("4b253b067525F35f94b6 
"hame" : "joe", 
"age" : 30, 
"sex" : "male", 
"location" : "Wisconsin" 
} 
JESE RHA Pee. BUSINES KIN BE 
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进去 ， 可 以 使 用 "$set": 

















> db.users.update({"_id" : ObjectId("4b253 
... {"$set" : {"favorite book" : "War and 




















之 后 文档 就 有 了 "favorite book" 键 。 








> db.users.findOne() 


{ 
"_id" : ObjectId("4b253b867525f35f94b6 
"name" : "joe", 
"age" : 30, 
"sex" : "male", 
"location" : "Wisconsin", 





"favorite book" : "War and Peace" 












































要 是 用 户 觉得 喜欢 的 其 实 是 另外 一 本 
"$set" 又 能 帮 上 忙 了 : 











> db.users.update({"name" : "joe"}, 
... {"$set" : {"favorite book" : "Green Eg 


























j"$set" 其 至 可 以 修改 键 的 类 型 。 例 如 ， 如 果 用 
户 觉 得 喜欢 很 多 本 书 ， 就 可 以 将 "favorit 
ebook" 键 的 值 变 成 一 个 数组 : 

> db.users.update({"name" : "joe"}, 


... {"$set" : {"favorite book" : 
one ["Cat's Cradle", "Foundation Trilo 













































































如 果 用 户 突然 发 现 自己 其 实 不 爱 读书 ， 可 以 
jj"$unset" 将 这 个 键 完全 删除 : 









































> db.users.update({"name" : "joe"}, 
... {"$unset" : {"favorite book" : 1}}) 














现在 这 个 文档 就 和 刚 开始 时 一 样 了 。 
也 可 以 用 "$set" 修 改 内 嵌 文 档 : 


> db.blog.posts.findone() 






































"_id" : ObjectId("4b253b067525F35F94b6 


"title" : "A Blog Post", 
"content" : "...", 
"author" : { 
"name" : "joe", 
"email" : "joe@example.com" 
} 
> db.blog.posts.update({"author.name" : "j 
... {"$set" : {"author.name" : "joe schmoe 


> db.blog.posts.findOne() 


"id" : ObjectId("4b253b067525F35F94b6 


"title" : "A Blog Post", 
"content" : "...", 
"author" : { 
"name" : "joe schmoe", 
"email" : "joe@example.com" 
} 





} 




















增加 、 修 改 或 删除 键 时 ， 应 该 使 用 $ 修 改 器 。 要 
把 "foo" 的 值 设 为 "bar"， 常 见 的 错误 做 法 如 
F: 


> db.coll.update (criteria, {"foo" : "bar"}) 















































这 会 事与愿违 。 实际 上 这 会 将 整个 文档 
j{"foo":"bar"} 蔡 换 掉 。 一 定 要 使 用 以 g 开 头 
的 修改 器 来 修改 键 / 值 对 。 


2. 增加 和 减少 


"$inc" 修 改 器 用 来 增加 已 有 键 的 值 ， 或 者 该 键 不 
存在 那 就 创建 一 个 。 对 于 更 新 分 析 数 据 、 因 果 关 
系 、 投 票 或 者 其 他 有 变化 数值 的 地 方 ， 使 用 这 个 
都 会 非常 方便 。 


假如 建立 了 一 个 游戏 集合 ， 将 游戏 和 变化 的 分 数 
都 存储 在 里 面 。 比 如 用 户 玩 弹 球 (pinball) 游 
戏 ， 可 以 插入 一 个 包含 游戏 名 和 玩家 的 文档 来 标 
识 不 同 的 游戏 : 































































































































































































> db.games.insert({"game" : "pinball", "us 

















要 是 小 球 撞 到 了 砖 块 ， 就 会 给 玩家 加 分 。 分 数 可 
以 随便 给 ， 这 里 就 把 玩家 得 分 基数 约定 成 50 好 
了 。 使 用 "$inc" 修 改 器 给 玩家 加 50 分 : 



























































> db.games.update({"game" : "pinball", "us 
. {"$inc" : {"score" : 50}}) 

















更 新 后 ， 可 以 看 到 : 




























































































> db.games.findOne() 
{ 
"_id" : ObjectId("4b2d75476cc613d5ee9 
"game" "pinball", 
"user" "joe", 
"score" : 50 
} 
分 数 (score) 键 原 来 并 不 存在 ， 所 以 "$inc" 创 
建 了 这 个 键 ， 并 把 值 设 定 成 增加 量 : 50。 
如 果 小 球 落 入 加 分 区 ， 要 加 10 000 分 。 只 要 
给 "$inc" 传 递 一 个 不 同 的 值 就 好 了 : 
> db.games.update({"game" "pinball", "us 
. {"$inc" "score" : 10000}}) 
现在 来 看 看 结 
> db.games.find() 
{ 
"_id" : ObjectId("4b2d75476cc613d5ee9 
"game" "pinball", 
"user" "joe", 
"score" : 10050 
} 











"score" 键 已 经 有 了 ， 而 且 有 




















个 数字 类 型 的 











值 ， 


"$inc" 
(和 减少 ) 数字 的 。 
型 或 双 精 度 浮 点 型 上 
据 上 就 会 导致 操作 失 郧 
及 数字 构成 的 


开 





些 类 型 














与 "$set" 的 用 
"$inc" 


的 值 。 














2> A oA 


要 是 用 在 其 
疏 ， 例 如 nu11、 TRR 


所 以 服务 器 就 给 这 个 值 增加 了 10 000. 
法 类 似 ， 就 是 专门 来 增加 


只 能 


用 于 整 型 、 长 整 
他 类 型 的 数 











字符 串 ， 而 在 
自动 转换 为 数值 类 


了 会 





型 者 
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也 很 多 语言 中 ， 这 











类 型 。 








> db.foo.insert({"count" 
> db.foo.update({}, {"$inc" 
Cannot apply $inc modifier to non-number 


TH 


: {"count" : 1 





另外 ， 
中 数 


中 、 











"$inc" 键 的 值 
组 或 其 他 非 数 字 的 1 














示 “Modifier"$inc"allowed for numbers only” 








必须 为 数字 。 不 能 使 用 
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。 和 否则 就 会 提 
( 修 


















































































































































改 器 "$inc" 只 人 允许 使 用 数值 类 型 ) 这样 的 错误 。 
要 修改 其 他 类 型 ， 应 该 使 用 "$set" 或 者 一 会 儿 要 
讲 到 的 数组 修改 器 。 

3. 数组 修改 器 

有 一 大 类 很 重要 的 修改 器 可 用 于 操作 数组 。 数 组 
是 常用 且 非 常 有 用 的 数据 结构 : 它们 不 仅 是 可 通 
过 索引 进行 引用 的 列表 ， 而 且 还 可 以 作为 数据 集 
(set) 来 用 。 





4. 添加 元 素 


如 果 数 组 已 经 存在 ，"$push" 会 向 已 有 的 数组 末 
尾 加 入 一 个 元 素 ， 要 是 没有 就 创建 一 个 新 的 数 
组 。 例 如 ， 假 设 要 存储 博客 文章 ， 要 添加 一 个 用 
于 保存 数组 的 "comments" GPH) 键 。 可 以 向 
还 不 存在 的 "comments" 数 组 添加 一 条 评论 ， 这 
个 数组 会 被 自动 创建 ， 并 加 入 一 条 评论 : 


> db.blog.posts.findone() 
{ 






















































































"_id" : ObjectId("4b2d75476cc613d5ee93 
"title" : "A blog post", 
"content" : "..." 


> db.blog.posts.update({"title" : "A blog 
. {"$push" : {" comments" 
"name" : "joe", "email" : "joe@exa 
"content" : "nice post. "}}}) 
> “db. blog.posts.findOne() 

{ 
"_id" : ObjectId("4b2d75476cc613d5ee93 
"title" : "A blog post", 

"content" : "..." 
"comments" : [ 


{ 


3 


"name" : "joe", 
"email" : "joe@example.com", 








"content" : "nice post." 


=~ 


























J"$push": 


过 


要 是 还 想 添加 一 条 评论 ， 继 续 使 


> db.blog.posts.update({"title" : "A blog 
. {"$push" : {" comments" 
"name" : "bob", "email" : "bob@ex 
"content" : "good post."}}}) 
> ‘dp. blog.posts.findone() 


{ 





”id”: ObjectId("4b2d75476cc613d5ee93 

"title" : "A blog post", 

"content" : "...", 

"comments" : [ 

{ 

"name" : "joe", 
"email" : "joe@example.com", 
"content" : "nice post. 


"name" : "bob", 
"email" : "bob@example.com", 
"content" : "good post. 



































ree as '$push" 使 用 形式 ， 也 可 以 
它 应 用 在 一 些 比较 复杂 使 

"geach" TIRE, 可 以 通过 一 次 "$push" 操 
作 添加 多 个 值 。 
























































> db.stock.ticker.update({"_id" : "GOOG"}, 
. {"$push" : {"hourly" : {"$each" : [562 
































这 样 就 可 以 将 三 个 新 元 素 添加 到 数组 中 。 如 果 指 
定 的 数组 中 只 含有 一 个 元 素 ， 那 这 个 操作 就 等 同 
于 没有 使 用 "$each" 的 普通 "$push" 操 作 。 


如 果 希 望 数组 的 最 大 长 度 是 固定 的 ， 那 么 可 以 
将 "$slice" 和 "$push" 组 合 在 一 起 使 用 ， 这 样 就 
可 以 保证 数组 不 会 超出 设 定好 的 最 大 长 度 ， 这 实 


























































































































际 上 就 得 到 了 一 个 最 多 包含 N 个 元 素 的 数组 : 
> db.movies.find({"genre" : "horror"}, 


... {"$push" : {"topie" : { 
x "$each" : ["Nightmare on Elm Stree 
"$slice" : -10}}}) 




















这 个 例子 会 限制 数组 只 包含 最 后 加 入 的 10 个 元 
素 。"$slice" 的 值 必须 是 负 整 数 。 


如 果 数 组 的 元 素数 量 小 于 10 ("$push" 之 后 ) ， 










































































那么 所 有 元 素 都 会 保留 。 如 果 数 组 的 元 素数 量 
于 10， 那 么 只 有 最 后 10 个 元 素 会 保留 。 因 
此 ，"$slice" 可 以 ] 来 在 文档 中 创建 一 个 队 
列 。 


最 后 ， 可 以 在 清理 元 素 之 前 使 用 "$sort"， 只 要 
向 数组 中 添加 子 对 象 就 需要 清理 : 


大 











all 





































































































> db.movies.find({"genre" : "horror"}, 
... {"$push" : {"topie" : { 
7 "$each" : [{"name" : "Nightmare on 
{"name" : "Saw", "ratin 
"$slice" : -10, 
"$sort" : {"rating" : -1}}}}) 








这 样 会 根据 "rating" 字 段 的 值 对 数组 中 的 所 有 
对 象 进行 排序 ， 然 后 保留 前 10 个 。 注 意 ， 不 能 只 
将 "$slice" 或 者 "$sort" 与 "$push" 配 合 使 用 ， 

且 必 须 使 用 "$each"。 


5. 将 数组 作为 数据 集 使 用 


你 可 能 想 将 数组 作为 集合 使 用 ， 保 证 数组 内 的 元 
素 不 会 重复 。 可 以 在 查询 文档 中 用 "$ne" 来 实 
现 。 例 如 ， 要 是 作者 不 在 引文 列表 中 ， 就 添加 进 
去 ， 可 以 这 么 做 : 


















































































































































> db.papers.update({"authors cited" : {"$n 
. {$push : {"authors cited" : "Richie"}} 




















岂可 以 用 "$addToSet" 来 实现 ， 要 知道 有 些 情 
况 "$ne" 根 本 行 不 通 ， 有 些 时 候 更 适合 
j"$addToSet"。 


列 如 ， 有 一 个 表示 用 户 的 文档 ， 己 经 有 了 电子 邮 
件 地 址 的 数据 集 : 


> db.users.findOne({"_id" : ObjectId("4b2d 
{ 







































































"_id" : ObjectId("4b2d75476cc613d5ee93 
"username" : "joe", 
"emails" : [ 
"joe@example.com", 
"joe@gmail.com", 
"joe@yahoo.com" 








} 


添加 新 地 址 时 ， 用 "$addToSet" 可 以 避免 插入 重 
复 地 址 : 


> db.users.update({"_id" : ObjectId("4b2d7 
. {"$addToSet" : {"emails" : "joe@gmail. 
> db.users.findOne({"_id" : ObjectId("4b2d 


{ 




















”id”: ObjectId("4b2d75476cc613d5ee93 
"username" : "joe", 
"emails" : [ 
"joe@example.com", 
"joe@gmail.com", 
"joe@yahoo.com", 
] 
} 
> db.users.update({"_id" : ObjectId("4b2d7 
... {"$addToSet" : {"emails" : "joe@hotmai 
> db.users.findOne({"_id" : ObjectId("4b2d 
{ 
"_id" : ObjectId("4b2d75476cc613d5ee93 
"username" : "joe", 
"emails" : [ 
"joe@example.com", 
"joe@gmail.com", 
"joe@yahoo.com", 
"joe@hotmail.com" 


} 











将 "$addToSet" 和 "$each" 组 合 起 来 ， 可 以 添加 
多 个 不 同 的 值 ， 而 用 "$ne" 和 "$push" 组 合 就 不 
能 实现 。 例 如 ， 想 一 次 添加 多 个 邮件 地 址 ， 就 可 
以 使 用 这 些 修 改 器 : 


> db.users.update({"_id" : ObjectId("4b2d7 






































. {"emails" : {"$each" 
[" 'joe@php. net" ed eas, 


> “db. users. findOne({"_ : ObjectId("4b2d 
{ 
"_id" : ObjectId("4b2d75476cc613d5ee93 
"username" : "joe", 
"emails" : [ 


"joe@example.com", 
"joe@gmail.com", 
"joe@yahoo.com", 
"joe@hotmail.com" 
"joe@php.net" 
"joe@python.org" 





} 








6. 删除 元 素 


有 几 个 从 数组 中 删除 元 素 的 方法 。 若 是 把 数组 看 
成 队列 或 者 栈 ， 可 以 用 "$pop"， 这 个 修改 器 可 以 
从 数组 任何 一 端 删除 元 素 。{"$pop": 
{"key" APAREA E 除 一 个 元 
素 ，{"$pop":{"Rey":-1}} 则 从 头 部 删除 。 


有 时 需要 基于 特定 条 件 来 删除 元 素 ， 而 不 仅仅 是 
依据 元 素 位 置 ， 这 时 可 以 使 用 "$pull"。 例 如 ， 
有 一 个 无 序 的 竺 完成 事项 列 39 
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> db.lists.insert({"todo" : ["dishes", "la 








要 是 想 把 洗衣 服 Caundry) 放 到 第 一 位 ， 可 以 从 
列表 中 先 把 它 删 掉 : 


> db.lists.update({}, {"$pull" : {"todo" : 























通过 查找 ， 会 发 现 只 有 两 个 元 素 了 : 


> db.lists.find() 





























{ 
"Vid" : ObjectId("4b2d75476cc613d5ee93 
"todo" : [ 
"dishes", 
"dry cleaning" 
] 
} 








"$pu11" 会 将 所 有 匹配 的 文档 删除 ， 而 不 是 只 删 
除 一 个 。 对 数组 [1,12,1] 执 行 pul1 1， 结 果 得 到 
只 有 一 个 元 素 的 数组 2。 


数组 操作 符 只 能 用 于 包含 数组 值 的 键 。 例 如 ， 不 
能 将 一 个 整数 插入 数组 ， 也 不 能 将 一 个 字符 串 从 
数组 中 弹出 。 要 修改 标量 值 ， 使 用 "$set" 或 
者 "$inc"。 
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7. 基于 位 置 的 数组 修改 器 


若是 数组 有 多 个 值 ， 而 我 们 只 想 对 其 中 的 一 部 分 
进行 操作 ， 就 需要 一 些 技巧 。 有 两 种 方法 操作 数 
组 中 的 值 : 通过 位 置 或 者 定位 操作 符 〈"$") 。 


数组 下 标 都 是 以 0 开头 的 ， 可 以 将 下 标 直 接 作为 
键 来 选择 元 素 。 例 如 ， 这 ， 其 中 包含 
由 内 据 文 档 组 成 的 数组 ， 比 如 包含 评论 的 博客 文 
章 。 
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> db.blog.posts.findOne() 


”id”: ObjectId("4b329a216cc613d5ee93 


"content" : "...", 
"comments" : [ 
{ 
"comment" : "good post", 
"author" : "John", 
"votes" : @ 
}s 
{ 
"comment" : "i thought it was 
"author" : "Claire", 
"votes" : 3 
}s 
{ 





"comment" : "free watches", 





"author" : "Alice", 
"votes" : -1 
} 


如 果 想 增加 第 一 个 评论 的 投票 数量 ， 可 以 这 么 
做 : 


> db.blog.update({"post" : post id}, 
. {"$inc" : {"comments.@.votes" : 1}}) 






































但 是 很 多 情况 下 ， 不 预先 查询 文档 就 不 能 知道 要 
修改 的 数组 的 下 标 。 为 了 克服 这 个 困难 ， 
MongoDB 提 供 了 定位 操作 符 "$"， 用 来 定位 查询 
文档 已 经 匹配 的 数组 元 素 ， 并 进行 更 新 。 例 如 ， 
要 是 用 户 John 把 名 字 改 成 了 Jim， 就 可 以 用 定位 符 
地 换 他 在 评论 中 的 名 字 : 


db.blog.update({"comments.author" : "John" 
. {"$set" : {"comments.$.author" : "Jim" 


























































































































定位 符 只 更 新 第 一 个 匹配 的 元 素 。 所 以 ， 如 果 
John 发 表 了 多 条 评论 ， 那 么 他 的 名 字 只 在 第 一 条 
评论 中 改变 。 


8. 修改 器 速度 























有 的 修改 器 运行 比较 快 。$inc 能 就 地 修改 ， 因 为 

















下 《对 文档 
而 数组 











不 需要 改变 文档 的 大 小 ， 只 需要 将 键 的 值 修改 一 
大 小 的 改变 非常 小 ) ， 所 以 非常 快 。 
侈 改 器 可 能 会 改变 文档 的 大 小 ， 就 会 慢 一 








E ("$set" 能 在 文档 大 小 不 发 生变 化 时 立即 修改 


它 ， 


将 文档 
磁盘 


否则 性 和 











ether Air PRE) 。 














插入 到 MongoDB 中 时 ， 依 次 插入 的 文档 在 
上 的 位 置 是 相 邻 的 。 因 此 ， 如 果 一 个 文档 变 






































大 了 ， 


档 就 会 














原先 的 位 置 就 放 不 下 这 个 文档 了 ， 这 个 文 








被 移动 到 集合 中 的 另 一 个 位 置 。 


























可 以 在 实际 操作 中 看 到 这 种 变化 。 创 建 一 个 包含 
几 个 文档 的 集合 ， 对 某 个 位 于 中 间 的 文档 进行 修 
改 ， 使 其 尺寸 变 大 。 然 后 会 发 现 这 个 文档 被 移动 


到 了 集合 的 









































尾部 : 





AV YY 一 一 一 YYVvYvYV 





-insert({"x" :"a"}) 

-insert({"x" :"b"}) 

-insert({"x" :"c"}) 

.find() 

: ObjectId("507c3581d87d6a342e1c81 
" : ObjectId("507c3583d87d6a342e1c81 
" : ObjectId("507c3585d87d6a342e1c81 
.update({"x" 
.find() 

" : ObjectId("507c3581d87d6a342e1c81 


"b"}, {$set: {"x" 





{ "_id" : ObjectId("507c3585d87d6a342e1c81 
{ "_id" : ObjectId("507c3583d87d6a342e1c81 





MongoDB 不 得 不 移动 一 个 文档 时 ， 它 会 修改 集合 
的 填充 因子 (padding factor〉。 填 充 因 子 是 
MongoDB 为 每 个 新 文档 预 留 的 增长 空间 。 可 以 运 
行 db .coll.stats() 查 看 填充 因子 。 执 行 上 面 的 
更 新 之 前 ，"paddingFactor" 字 段 的 值 是 1: 根 
据 实际 的 文档 大 小 ， 为 每 个 新 文档 分 配 精 确 的 空 
间 ， 不 预 留任 何 增长 空间 ， 如 图 3-1 所 示 。 让 其 ! 
一 个 文档 增 大 之 后 ， 再 次 运行 这 个 命令 〈 如 图 3-2 
所 示 ) ， 会 发 现 填充 因子 增加 到 了 1.5: 为 每 个 新 
文档 预 留 其 一 半 大 小 的 空间 作为 增长 空间 ， 如 图 
3-2 所 示 。 如 果 随 后 的 更 新 导致 了 更 多 次 的 文档 移 
动 ， 填 充 因子 会 持续 变 大 《虽然 不 会 像 第 一 次 移 
动 时 的 变化 那么 大 ) 。 如 果 不 再 有 文档 移动 ， 填 
充 因子 的 值 会 缓慢 降低 ， 如 图 3-3 所 示 。 
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At 




















图 3-1 最初， 文档 之 间 没 有 多 余 的 空间 











图 3-2 





Te 


因 





如 果 一 个 文书 




















Wi eu 


为 体积 变 大 而 不 得 不 进 





行 移动 ， 它 原先 占用 的 空间 就 闲置 了 ， 而 且 填 
充 因子 会 增加 


























图 3-3 之 后 插入 的 新 文档 都 会 拥有 填充 因子 指 


定 大 小 的 增长 空间 。 勾 

















I 果 在 之 后 的 插入 中 不 再 


发 生 文档 移动 ， 填 充 因子 会 逐渐 变 小 


档 是 非常 慢 的 。MongoDB 必 须 将 文档 原先 
所 占 的 空间 释放 掉 ， 然 后 将 文档 写 入 另 一 片 空 
此 ， 应 该 尽量 让 填充 因子 的 值 接近 1。 无 


移动 文 











fa]. A 
































法 手动 
压缩 ， 


于 文档 、 




















设 定 填 充 因子 的 值 〈 除 非 是 要 对 集合 进行 





参见 18.4 节 ) ， 但 





绍 模式 设计 的 相关 内 容 。 








是 可 以 设计 一 种 不 依赖 


可 以 任意 增长 的 模式 。 第 8 章 会 详细 介 
































下 面 用 





动 的 速度 差别 。 下 











个 简单 的 程序 来 展示 原 地 更 新 和 文档 移 

















有 的 程序 插入 了 一 个 只 包含 一 























个 键 的 文档 ， 并 且 对 这 个 键 的 值 进行 了 100 000 次 


增加 : 








> db.tester.insert({"x" : 1}) 
> var timeInc = function() { 
. var start = (new Date()).getTime(); 


. for (var i=@; i<100000; i++) { 
db.tester.update({}, {"$inc" : {"x 
db.getLastError(); 


- 】} 


. var timeDiff = (new Date()).getTime() 
. print("Updates took: "+timeDiff+"ms") ; 








> timeInc() 














在 MacBook Air 上， 总 共 花 费 了 7.33 秒 。 也 就 是 每 
秒 超过 13 000 次 更 新 。 现 在 ， 使 用 "$push" 向 一 
个 只 有 一 个 键 的 数组 中 插入 新 数据 ， 重 复 100 000 
次 。 将 上 面 例子 中 用 于 更 新 文档 的 代码 修改 为 : 






























































db.tester.update({}, {"$push" : {"x" 





这 个 程序 运行 时 间 为 67.58 秒 ， 每 秒 少 于 1500 次 更 
使 用 "$push" 以 及 其 他 一 些 数组 修改 器 是 非常 好 


的 ， 而 且 通 常 是 必要 的 ， 但 是 ， 在 进行 类 似 的 更 
新 时 ， 需 要 好 好 权衡 一 下 。 如 果 "$push" 成 为 了 




















































































































































































































瓶颈 ， 那 么 将 一 个 内 髓 文档 取出 放 入 一 个 单独 的 
集合 中 ， 手 动 填充 ， 或 者 使 用 第 8 章 将 要 介绍 的 
其 他 某 项 技术 ， 都 很 值得 。 

写作 本 书 时 ，MongoDB 仍 然 不 能 很 好 地 重用 空白 
空间 ， 因 此 频繁 移动 文档 会 产生 大 量 空 的 数据 文 
牛 。 如 果 有 太 多 不 能 重用 的 空白 空间 ， 你 会 经 常 
在 日 志 中 看 到 如 下 信息 : 

















Thu Apr 5 01:12:28 [conn124727] info DFM: :| 


Centire extent， 可 以 在 附录 了 B: 
简单 来 说 ， 
不 到 任何 文档 : 这 只 是 个 空 
个 消息 提示 本 身 没 什么 影响 ， 但 是 它 指 


找 ， 却 找 



































执行 查询 时 ，MongoDB 会 在 整个 范 
查看 相关 定义 。 














它 就 是 集合 的 





个 子 集 ) 内 














进行 查 




















空间 。 这 















































拥有 太 多 


如 果 你 的 
移动 或 者 















































的 碎片 ， 可 能 需要 进行 压缩 。 


模式 在 进行 插入 和 

















是 经 常 打 乱 数据 ， 可 以 使 


jusePowerOf2Sizes 选 项 以 提 
可 以 通过 co11Mod 命 令 来 设 定 这 个 选项 : 


出 你 当前 


出 除 时 会 进行 大 量 的 








高 磁盘 复 用 率 。 








> db.runCommand ({"col1Mod" 


: collectionName, "usePowd 








这 个 集合 之 后 进行 的 所 有 空间 分 配 ， 得 到 

















WARK 





小 都 是 2 的 苏 。 由 于 这 个 选 


























硕 会 导致 初始 空间 分 














配 不 再 那么 高 效 ， 所 以 应 该 只 在 需要 经 常 打 乱 数 
据 的 集合 上 使 用 。 在 一 个 只 进行 插入 或 者 原 地 更 
































新 的 集合 上 使 用 这 个 选项 ， 


慢 。 























会 导致 号 入 速度 变 


如 果 在 这 个 命令 中 指定 "usePower0f2Sizes" 选 
项 的 值 为 false， 就 会 关闭 这 种 特殊 配 机 制 |。 














这 个 选项 只 会 影响 之 后 新 分 











> 配 的 记录 ， 因 此 ， 在 





























3.3.3 upsert 








己 有 的 集合 上 运行 这 个 命令 或 者 是 更 改 这 个 选项 
的 值 ， 不 会 对 现 有 数据 产生 影响 。 














upsert 是 一 种 特殊 的 更 新 。 
新 条 件 的 文 要 ， 就 会 以 这 个 


要 是 没有 找到 符合 更 
条 件 和 更 新 文档 为 基 












































础 创建 一 个 新 的 文档 。 如 果 找 到 了 匹配 的 文档 ， 



































文档 。 








则 正常 更 新 。upsert 非 常 方便 ， 不 必 有 预 置 集合 
同一 套 代码 既 可 以 用 于 创建 文档 又 可 以 用 于 更 




















有 


























我 们 回 过 头 看 看 那个 记录 网 











子 。 要 是 没有 upsert， 就 得 


站 页 面 访问 次 数 的 例 




















Hi BURL, BA 














RAMEE TIC, FRB TE RH I al AR 
数 。 要 是 把 这 个 写成 JavaScript 和 程序， 会 是 下 面 这 





样 的 : 








// 检查 这 个 页 面 是否 有 一 个 文档 
blog = db.analytics.findOne({url : "/blog" 











// 如 果 有 ， 就 将 视图 数 加 /并 保存 
if (blog) { 
blog. pageviews++; 
db.analytics.save(blog) ; 

















} 

// 否则 为 这 个 页 面 创建 一 个 新 文档 

else { 
db.analytics.save({url : "/blog", page 

} 






































这 就 是 说 如 果 有 人 访问 页 面 ， 我 们 得 先 对 数据 库 
进行 查询 ， 然 后 选择 更 新 或 者 插入 。 要 是 多 个 进 
程 同时 运行 这 段 代 码 ， 还 会 遇 到 同时 对 给 定 URL 
插入 多 个 文档 这 样 的 竞 态 条 件 。 










































































要 是 使 用 upsert， 既 可 以 避免 竟 态 问题 ， 又 可 以 
缩减 代码 量 (update 的 第 3 个 参数 表示 这 是 
个 upsert) : 














db.analytics.update({"url" : "/blog"}, {"$ 












































II 





这 行 代码 和 之 前 的 代码 作用 完全 一 样 ， 但 它 更 








效 ， 并 且 是 原子 性 的 ! 创 建新 文档 会 将 条 件 文档 作 
为 基础 ， 然 后 对 它 应 用 修改 器 文档 。 


例如 ， 要 是 执行 一 个 匹配 键 并 增加 对 应 键 值 的 
upsert 操 作 ， 会 在 匹配 的 文档 上 进行 增加 : 













































































> db.users.update({"rep" : 25}, {"$inc" 

> db.users.findOne() 

{ 
"_id" : ObjectId("4b3295f26cc613d5ee93 
"rep" : 28 





} 

















upsert 创 建 一 个 "rep" 值 为 25 的 文档 ， 随后 将 这 
个 值 加 3， 最 后 得 到 "rep" 为 28 的 文档 。 要 是 不 指 
定 upsert 选 项 ，{"rep":25} 不 会 匹配 任何 文 

档 ， 也 就 不 会 对 集合 进行 任何 更 新 。 


要 是 再 次 运行 这 个 upsert 《条 件 为 
{"rep":25}) ， 还 会 创建 一 个 新 文档 。 这 是 医 
为 没有 文档 满足 匹配 条 件 〈 唯 一 一 个 文档 
的 "rep" 值 是 28) 。 


有 时 ， 需要 在 创建 文档 的 同时 创建 字段 并 为 它 赋 
值 ， 但 是 在 之 后 的 所 有 更 新 操作 中 ， 这 个 字段 的 
E 这 就 是 "$setonInsert" 的 作 

"$setOonInsert" 只 会 在 文档 插入 时 设置 字 



















































































































































































段 的 值 。 因 此 ， 实 际 使 用 中 可 以 这 么 做 ; 





> db.users.update({}, {"$setOnInsert" : {" 
> db.users.findOne() 


{ 


"_id" : ObjectId("512b8aefae74c67969e4 
"createdAt" : ISODate("2013-02-25T16:0 


























如 果 再 次 运行 这 个 更 新 ， 会 匹配 到 这 个 已 存在 的 
文档 ， 所 以 不 会 再 插入 文档 ， 
此 "createdAt" 字 上 段 的 值 也 不 会 改变 : 















































> db.users.update({}, {"$setOnInsert" : {" 
> db.users.findOne() 


{ 


"_id" : ObjectId("512b8aefae74c67969e4 
"createdAt" : ISODate("2013-02-25T16:0 























注意 ， 通常 不 需要 | 这 样 的 字 
段 ， 因 为 0bjectIds 里 包含 了 一 个 用 于 标明 文档 
创建 时 间 的 时 间 戳 。 但 是 在 预 置 或 者 初始 化 计 
数 器 时 ， 或 者 是 对 于 不 使 用 ObjectIds 的 集合 来 
说 ，"$setOonInsert" 是 非常 有 用 的 。 





































































































save shell 帮 助 程序 

















save 是 一 个 shell 函 数 ， 如 果 文 档 不 存在 ， 它 会 
动 创建 文档 ; 如 果 文 档 存 在 ， 它 就 更 新 这 个 文 
档 。 它 只 有 一 个 参数 : 文档。 要 是 这 个 文档 含 
有 "id" 键 ，save 会 调用 upsert。 和 否则 ， 会 调 
jinsert。 如 果 在 Shell 中 使 用 这 个 函数 ， 就 可 以 
非常 方便 地 对 文档 进行 快速 修改 。 


b.foo.findOne() 
2 





























































































































Aa 








> db.foo.save(x) 























要 是 不 用 save 的 话 ， 最 后 一 行 代 码 看 起 来 就 会 比 
较 繁 琐 了 ， 比 如 db.foo.up date({"_id" : 
X. id}, x). 





3.3.4 更 新 多 个 文档 











默认 情况 下 ， 更 新 只 能 对 符合 匹配 条 件 的 第 一 个 
文档 执行 操作 。 要 是 有 多 个 文档 符合 条 件 ， 只 有 
第 一 个 文档 会 被 更 新 ， 其 他 文档 不 会 发 生变 化 。 

要 更 新 所 有 匹配 的 文档 ， 可 以 将 update 的 第 4 个 


参数 设置 为 true。 































































































update 的 行为 以 后 可 能 会 发 生变 化 








(服务 器 可 能 默认 会 更 
有 第 4 个 参数 为 false 才 会 








更 新 所 有 匹配 的 文档 ， 只 














只 更 新 一 个 ) ， 所 以 



































建议 每 次 都 显 式 表 明 要 不 要 做 多 文档 更 新 。 
这 样 不 但 更 明确 地 指定 了 update 的 行为 ， 而 
可 以 在 默认 行为 发 生变 化 时 正常 运行 。 
































多 文档 更 新 对 模式 迁移 非常 有 用 ， 还 可 以 在 对 特 








定 用 户 发 布 新 功能 时 使 用 。 
定 日 期 过 生日 的 所 有 用 户 一 份 




































































例如 ， 要 送 给 在 个 指 




















} 礼 物 ， 就 可 以 使 用 














多 文档 更 新 ， 将 "gift" 增 加 到 他 们 的 账号 : 
> db.users.update({"birthday" : "10/13/197 





. {"$set" : {"gift" 


"Happy Birthday! "} 








这 样 就 给 生日 为 1978 年 10 月 13 日 的 所 有 























添加 了 "gift" 键 。 











户 文 档 











op 

















想 要 知道 多 文档 更 新 到 底 更 3 


运行 getLastError 命 令 〈 可 








一 次 操作 的 相关 信息 ”) 。 
文档 的 数量 。 

















键 " 


所 了 多 少 文档 ， 可 以 





以 理解 为 “返回 最 后 
n" 的 值 就 是 被 更 新 











> db.count.update({x : 1}, {$inc : {x : 1} 
> db.runCommand({getLastError : 1}) 


"err" : null, 
"updatedExisting" : true, 
"A" :5, 

"ok" : true 




















这 里 "n" 为 5， 说 明 有 5 个 文档 被 更 新 
了 。"updatedExisting" 为 true， 说 明 是 对 已 
有 的 文档 进行 更 新 。 
































3.3.5 ”返回 被 更 新 的 文档 

















调用 getLastError 仅 能 获得 关于 更 新 的 有 限 信 
轧 ， 并 不 能 运 问 被 更 新 的 文档 。 可 以 通过 
findAndModify 命 令 得 到 被 更 新 的 文档 。 这 对 于 
操作 队列 以 及 执行 其 他 需要 进行 原子 性 取 值 和 赋 
值 的 操作 来 说 ， 十 分 方便 。 

















































































































假设 我 们 有 一 个 集合 ， 其 中 包含 以 一 定 顺序 运行 
的 进程 。 其 中 每 个 进程 都 用 如 下 形式 的 文档 表 
JR: 








{ 


”id”: ObjectId(), 
"status" : state, 
"priority" : N 

} 


"status" 个 字符 串 ， 它 的 值 可 以 
2 TERUNA ING 二 AN 需要 找到 状 
态 为 "READY" 具有 最 高 优先 级 的 任务 ， 运 行 相 应 
的 进程 函数 ， 然后 将 其 状态 更 新 为 "DONE"。 也 可 
能 需要 查询 已 经 就 绪 的 进程 ， 按 照 优 先 级 排序 ， 

然后 将 优先 级 最 高 的 进程 的 状态 更 š 
为 "RUNNING" 。 完 成 了 以 后 ， 就 把 状态 改 
为 "DONE"。 就 像 下 面 这 样 : 


var cursor = db.processes.find({"status" 
ps = cursor.sort({"priority" : -1}).limit( 
db.processes.update({"_id" : ps._id}, {"$s 
do_something(ps) ; 
db.processes.update({"_id" : ps._id}, {"$s 























































































































SSE EAR, ARES SRE ATE. it 

有 两 个 线程 正在 运行 。A 线 程 读 取 了 文档 ，B 线 程 

在 A 将 文档 状态 改 为 "RUNNING" 之 前 也 读 取 了 同 

一 个 文档 ， 这 样 两 个 线程 会 运行 相同 的 处 理 过 

程 。 昌 然 可 以 在 更 新 查询 中 进行 状态 检查 来 避免 
这 一 问题 ， 但 是 十 分 复杂 













































































var cursor = db.processes.find({"status" 
cursor.sort({"priority" : -1}).limit(1); 
while ((ps = cursor.next()) != null) { 
ps.update({"_id" : ps._id, "status" 
{"$set" : {"status" : "RUNNI 
var lastOp = db.runCommand({getlasterr 
if (lastOp.n == 1) { 
do_something(ps) ; 
db.processes.update({"_id" : ps._i 
break; 


cursor = db.processes.find({"status" 
cursor.sort({"priority" : -1}).limit(1 





} 


这 样 也 有 问题 。 因 为 有 先 有 后 ， 很 可 能 一 个 线程 
处 理 了 所 有 任务 ， 而 另外 一 个 就 傻 傻 地 采 在 那 
里 。A 线 程 可 能 会 一 直 占 用 着 进程 ，B 线 程 试 着 


占 失败 后 ， 就 让 A 线程 自己 处 理 所 有 任务 了 。 


过 到 类 似 这 样 的 情况 时 ，findAndModify 就 可 大 
显 身手 了 。findAndModify 能 够 在 一 个 操作 中 返 
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回 匹配 结果 并 且 进 行 更 新 。 在 本 例 中 ， 处 理 过 程 
如 下 所 示 : 














> ps = db.runCommand({"findAndModify" : 
"query" : {"status" : "READY"}, 
"sort" : {"priority" : -1}, 






























































































































... "update" : {"$set" : {"status" : "RUNN 
{ 
"ok" : 1, 
"value" : { 
"_id" : ObjectId("4b3e7a18005cab32 
"priority" : 1, 
"status" "READY" 
} 
} 
注意 ， 返 回 文档 中 的 状态 仍然 为 "READY"， Al 
为 findAndModify 返 可 的 是 修改 之 前 的 文档 。 
URERA E KEM, ARIRNI 
H" status" 已 经 更 新 成 了 "RUNNING " : 
> db.processes.findOne({"_id" : ps.value._| 
{ 
"_id" : ObjectId("4b3e7a18005cab32be62 
"priority" : 1, 
"status" : "RUNNING" 
} 
这 样 的 话 ， 程 序 就 变 成 了 下 面 这 样 : 
ps = db.runCommand({"findAndModify" : "pro 
"query" : {"status" : "READY"}, 
"sort" : {"priority" : -1}, 
"update" : {"$set" : {"status" : "RUNN 





do_something(ps) 
db.process.update({"_id" : ps._id}, {"$set 








findAndModify 可 以 使 用 "update" 键 也 可 以 使 
"remove" 键 。"remove" 刍 表示 将 匹配 的 文档 
从 集合 里 面 删除 。 例 如 ， 现 在 不 用 更 新 状态 了 ， 
而 是 直接 删 掉 ， 就 可 以 像 下 面 这 样 : 































































































ps = db.runCommand({"findAndModify" : "pro 
"query" : {"status" : "READY"}, 
"sort" : {"priority" : -1}, 
"remove" : true}).value 
do_something(ps) 























findAndModify 命 令 有 很 多 可 以 使 用 的 字段 。 





e findAndModify 





FHR, RA 





e query 


查询 文档 ， 用 于 检索 文档 的 条 件 。 














e sort 


排序 结果 的 条 件 。 





























e update 


修改 器 文档 ， 用 于 对 匹配 的 文档 进行 更 新 
Cupdate 和 remove 必 须 指 定 一 个 ) 。 























e remove 


布尔 类 型 ， 表 示 是 否 删除 文档 〈remove 和 
update 必 须 指定 一 个 ) 。 











e new 




















布尔 类 型 ， 表 示 返 回 更 新 前 的 文档 还 是 更 新 
后 的 文档 。 默 认 是 更 新 前 的 文档 。 









































a fields 
文档 中 需要 返回 的 字段 CE) 。 
e upsert 





布尔 类 型 ， 值 为 true 时 表示 这 是 一 
个 upsert。 默 认为 false。 





a a 个 ， 也 只 能 有 一 
。 要 是 没有 匹配 的 文档 ， 这 个 命令 会 返回 一 个 


HR o 




















34 写 入 安全 机 制 








写 入 安全 (Write Concern) 是 一 种 客户 端 设置 ， 

















于 控制 写 入 的 安全 级 另 








时 ， 客 














有 一 k) 
的 内 容 。 


入 (acknowledged wirte) 和 非 
Cunacknowledged write) 。 


方式 : 数据 库 会 给 出 啊 应 ， 


川 除 和 更 新 都 会 一 ] 
成 功 ) ， 然 后 才 会 继 纪 SUT 
Rie 《有些 
中 “异常 "， 不 过 实质 上 都 是 


选项 可 以 用 于 精确 控制 
两 种 最 基本 的 写 入 安全 机 秆 




















户 端 会 抛 出 一 个 























1。 默认 情况 下 ， TA 
寺 数 据 库 响应 ( 写 入 是 














ke ona 
语言 a 言 中 可 能 不 








是 类 似 的 东西 ) 。 





应 


万 





需要 应 用 程序 等 竺 
I 是 应 答 式 写 
应 答 式 写 入 











答 式 写 入 是 默认 的 


fas en 


沂 你 写 入 操作 是 否 








成 功 执行 。 非 应 








无 

















者 是 批量 加 载 数据 ) ， 你 可 能 不 愿意 为 J 
关心 的 数据 而 等 待 数据 库 


法 知道 


通常 来 说 ， 应 
十; 对 于 一 些 


写 入 是 否 成 功 。 


程序 


























应 该 使 
不 是 特别 时 要 


答 式 写 入 不 返 





习 任 何 响应 ， 所 以 























应 答 式 写 入 。 但 

















的 











数据 (比如 日 志 或 


























可 以 使 


尽管 非 应 答 





代表 应 
经 关闭 








] 非 应 答 式 写 入 。 








A 

















响应 。 在 这 种 情况 下 ， 








式 写 入 不 返 世 
程序 不 需要 做 错 
































数据 
误 检查 。 如 果 尝 试 向 已 
HERF (socket) 执行 





EHR, (HERS 


























写 入 ， 或 者 写 入 


套 接 字 时 发 生 了 错误 ， 都 会 引起 异常 。 


使 用 非 应 答 式 写 入 时 ， 一 种 经 常 被 忽视 的 错误 是 
插入 无 效 数据 。 比 如 ， 如 果 试 图 插入 两 个 具有 相 
同 "_id" 字 段 的 文档 ，shell 就 会 抛 出 异常 

































































> db.foo.insert({"_id" : 1}) 
> db.foo.insert({"_id" : 1}) 
E11666 duplicate key error index: test.foo 






































如 果 第 二 次 插入 时 使 用 的 是 非 应 答 式 写 入 ， 那 么 
第 二 次 插入 就 不 会 抛 出 异常 。 键 重复 异常 是 一 种 
非常 常见 的 错误 ， 还 有 其 他 很 多 类 似 的 错误 ， 比 
如 无 效 的 修改 器 或 者 是 磁盘 空间 不 足 等 。 


shell 与 客户 端 程序 对 非 应 答 式 写 入 的 实际 支持 并 
不 一 样 : shell 在 执行 非 应 答 式 写 入 后 ， 会 检查 最 
后 一 个 操作 是 否 成 功 ， 然 后 才 会 向 用 户 输出 提示 
言 息 。 因 此 ， 如 果 在 集合 上 执行 了 一 系列 无 效 操 
作 ， 最 后 又 执行 了 一 个 有 效 操作 ，shell 并 不 会 提 
示 有 错误 发 生 。 

















































































































> db.foo.insert({"_id" : 1}); db.foo.inser 
1 


























可 以 调用 getLastError 手动 强制 在 shell 中 进行 检 
查 ， 这 一 操作 会 检查 最 后 一 次 操作 中 的 错误 
































> db.foo.insert({"_id" : 1}); db.foo.inser 
. db.getLastError()); db.foo.count() 
















































































£11000 duplicate key error index: test.foo 
1 

编写 需要 在 shell 中 执行 的 脚本 时 ， 这 是 非常 有 用 
的 。 

事实 上 ， 还 有 其 他 一 些 写 入 安全 机 制 ， 第 11 章 会 
讲述 多 台 服 务 器 之 间 的 写 入 安全 ， 第 19 章 会 讲述 
写 入 提交 











,2012 年 ， 默 认 的 写 入 安全 机 制 改变 
， 所 以 ， 遗 留 代码 的 行为 可 能 会 与 预期 不 一 
致 。 在 此 之 前 ， 默 认 的 写 入 是 非 应 答 式 的 。 

幸好 ， 很 容易 得 知 当前 代码 是 在 默认 的 写 入 安 

















全 机 种 





1] 发 生变 化 之 前 写 的 还 是 之 后 写 的: 





默认 


的 写 入 机 制 


变 为 安全 写 入 之 后 ， 











Ay 





区 动 程序 









































都 开始 使 ) 





WAX, J 





不 安全 的 API。 











象 是 Mongo 或 才 
那么 这 段 程序 使 用 的 就 是 旧 的 、 
在 默认 写 入 安全 机 种 












































jMongoClient 这 个 类 。 如 果 程 / 


用 的 连接 对 Connection 或 者 其 





sigh 
其 





默认 


I 发 生变 化 














之 前 ， 任 何 语言 都 没有 使 用 MongoClient 作 为 
类 名 ， 所 以 ， 如 果 你 的 代码 使 用 了 这 个 类 名 ， 
说 明 你 的 代码 是 写 入 安全 如 果 使 用 的 连接 
不 是 MongoClient， 应 在 必要 时 将 旧 代 码 中 的 
非 应 答 式 写 入 改 成 应 答 式 写 入 。 
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使 

据 库 执行 查询 ; 
。 使 用 $ 条 件 查 

查 

查 

















mt 
































询 实 现 范围 查询 、 
询 、 T a 些 查 询 ; 





详细 介绍 查询 。 主 要 会 涵盖 以 下 几 个 方 


find 或 者 findone 函 数 和 查询 文档 对 数 





数据 集 包含 





























ewe 需要 的 文档 批量 


查询 将 会 这 也 一 个 数据 库 游 标 ， 游标 只 会 在 











返回 ; 














Se ee 包括 忽略 




















E e 
































量 ’ 以 及 对 结 果 排 序 





4.1 find 简 介 


























MongoDB 中 使 用 find 来 进行 查询 。 














回 结果 的 数 


查询 就 是 返回 

















一 个 集合 中 文档 的 子 集 ， 子 集合 的 范围 从 0 个 文 














档 到 整个 集合 。find 的 第 一 个 参数 决定 了 要 返 臣 
哪些 文档 ， 这 个 参数 是 一 个 文档 ， 





条 件 。 





空 的 查询 文档 (例如 个 〉 会 匹配 集合 
容 。 要 是 不 指定 查询 文档 ， 






























































于 指定 查询 








的 全 部 内 


默认 就 是 {}。 例 如 : 








> db.c.find() 























将 批量 返回 集合 c 中 的 所 有 文档 。 
查 


] 查 询 文档 中 添加 键 / 值 对 时 ， 就 意味 着 限定 
了 查询 条 件 。 对 于 绝 大 多 数 类 型 来 说 ， 这 种 方式 
很 简单 明了 。 数 值 匹 配 数值 ， 布 尔 类 型 匹配 布尔 
类 型 ， 字 符 串 匹 配 字 符 串 。 查 询 简 单 的 类 型 ， 只 
要 指定 想 要 查找 的 值 就 好 了 ， 十 分 简单 。 例 如 ， 
想 要 查找 "age" 值 为 27 的 所 有 文档 ， 直 接 将 这 样 的 
键 / 值 对 写 进 查询 文档 就 好 了 : 












































































































































> db.users.find({"age" : 27}) 

















要 是 想 匹 配 一 个 字符 串 ， 比 如 值 
为 "joe" 的 "username" 键 ， 那 么 直接 将 键 / 值 对 
写 在 查询 文档 中 即 可 : 


> db.users.find({"username" : "joe"}) 













































































可 以 向 查询 文档 加 入 多 个 键 / 值 对 ， 将 多 个 查询 条 
件 组 合 在 一 起 ， 这 样 的 查询 条 件 会 被 解释 成 “条 

件 1AND 条 件 2AND ... AND 条 件 N”。 例 如 ， 要 想 
查询 所 有 用 户 名 为 joe 且 年 龄 为 27 岁 的 用 户 ， 可 以 
像 下 面 这 样 : 
















































































> db.users.find({"username" : "joe", "age" 

















41.1 指定 需要 返回 的 键 





有 时 并 不 需要 将 文档 中 所 有 键 / 值 对 都 返回 。 遇 到 
这 种 情况 ， 可 以 通过 find (或 者 findone) 的 第 
二 个 参数 来 指定 想 要 的 键 。 这 样 做 既 会 节省 传输 
的 数据 量 ， 又 能 节省 客户 端 解码 文档 的 时 间 和 内 
存 消耗 。 


例如 ， 如 果 只 对 用 户 集合 
的 "username" 和 "email" 键 感 兴趣 ， 可 以 使 用 如 
下 查询 返回 这 些 键 : 














































































































> db.users.find({}, {"username" : 1, "emai 
{ 
"_id" : ObjectId("4baðfðdfd22aa494fd52 
"username" : "joe", 
"email" : "joe@example.com" 


} 


可 以 看 到 ， 默 认 情 况 下 "_id" 这 个 键 总 是 被 返 
回 ， 即 便 是 没有 指定 要 返回 这 个 键 。 


也 可 以 用 第 二 个 参数 来 剔除 查询 结果 中 的 某 些 键 / 
值 对 。 例 如 ， 文 档 中 有 很 多 键 ， 但 是 我 们 不 希望 








































































































结果 中 含有 "fatal_weakness" 键 : 











> db.users.find({}, {"fatal_weakness" : @} 














使 用 这 种 方式 ， 也 可 以 把 ”id" 键 剔除 掉 : 














> db.users.find({}, {"username" : 1, "_id" 
{ 
"username" : "joe", 
} 
4.1.2 限制 








查询 的 使 用 上 有 些 限制 。 传 递 给 数据 库 的 查询 文 
档 的 值 必须 是 常量 。 (在 你 自己 的 代码 里 可 以 是 
正常 的 变量 。) 也 就 是 不 外 g 引 用 文档 中 其 他 键 的 
值 。 例 如 ， 要 想 保 持 库 存 ， 有 "in_stock" CB 
RE) 和 "num_so1d" (GHS) 两 个 键 ， 想 
通过 下 列 查询 来 比较 两 者 的 值 是 行 不 通 的 : 


> db.stock.find({"in_stock" : "this.num_s 


































































































的 确 有 办 法 实现 类 似 的 操作 ( 详 见 4.4 节 ) 

常 需要 略微 修改 一 下 文档 结构 ， 就 能 通过 普通 
询 来 完成 这 样 的 操作 了 ， 这 种 方式 性 能 更 好 。 
这 个 例子 中 ， 可 以 在 文档 中 使 


， 但 





通 
查 
在 



































J"initial stock" (初始 库存 ) 

和 "in_stock" 两 个 键 。 这 样 ， 每 当 有 人 购买 物 
品 ， 就 将 "in_stock" 减 去 1。 这 样 ， 只 需要 用 一 
个 简单 的 查询 就 能 知道 哪 种 商品 己 脱 销 : 


> db.stock.find({"in_stock" : 08}) 
4.2 ”查询 条 件 


查询 不 仪 能 像 前 面 说 的 那样 精确 匹配 ， 还 能 匹配 
更 加 复杂 的 条 件 ， 比 如 范围 、OR 子 句 和 取 反 。 













































































4.2.1 ”查询 条 件 





RS ltt It "$gt" 和 "$gte" 就 是 全 部 的 比 
较 操 作 符 ， 分 别 对 应 <、<=、> 和 >=。 可 以 将 其 组 
合 起 来 以 便 碍 找 个 范围 的 值 。 例 如 ， 查 询 
18~30 岁 〈 含 ) 的 用 户 ， 就 可 以 像 下 面 这 样 : 



























































> db.users.find({"age" : {"$gte" : 18, "$1 


这 样 就 可 以 查找 到 "age" 字 段 大 于 等 于 18、 小 于 
等 于 30 的 所 有 文档 。 


这 样 的 范围 查询 对 日 期 尤为 有 有 用。 例如， 要 查找 
在 2007 年 1 月 1 日 前 注册 的 人 ， 可 以 像 下 面 这 样 : 


































































































> start = new Date("01/01/2007") 
> db.users.find({"registered" : {"$1t" : s 





























可 以 对 日 期 进行 精确 匹配 ， 但 是 用 处 不 大 ， 因 为 
文档 中 的 日 期 是 精确 到 毫秒 的 。 而 我 们 通常 是 想 
得 到 一 天 、 一 周 或 者 是 一 个 月 的 数据 ， 这 样 的 
话 ， 使 用 范围 查询 就 很 有 必要 了 。 

对 于 文档 的 键 值 不 等 于 某 个 特定 值 的 情况 ， 就 要 
使 用 另外 一 种 条 件 操作 符 "$ne" 了 ， 它 表示 “不 相 
等 ”。 若是 想 要 查询 所 有 名 字 字 不 为 joe 的 用 户 ， 可 
以 像 下 面 这 样 查 询 : 


> db.users.find({"username" : {"$ne" : "jo 

































































































































































"$ne" 能 用 于 所 有 类 型 的 数据 。 











4.2.2 ”OR 查询 








MongoDB 中 有 两 种 方式 进行 OR 查询 : "$in" 可 以 
] 来 查询 一 个 键 的 多 个 值 ，"$or" 更 通用 一 些 ， 
可 以 在 多 个 键 中 查询 任意 的 给 定 值 。 


如 果 一 个 键 需要 与 多 个 值 进行 匹配 的 话 ， 就 要 
j"$in" 操 作 符 ， 再 加 一 个 条 件数 组 。 例 如 ， 抽 
奖 活动 的 中 奖 号 码 是 725、542 和 390。 要 找 出 全 















































































































































部 的 中 奖 文档 的 话 ， 可 以 构建 如 下 查询 : 


> db.raffle.find({"ticket_no" : {"$in" : [ 


























"$in" 非 常 灵 活 ， 可 以 指定 不 同类 型 的 条 件 和 
值 。 例 如 ， 在 逐步 将 用 户 的 人 D 号 迁移 成 用 户 名 的 
过 程 中 ， 查 询 时 需要 同时 匹配 ID 和 用 户 名 : 


> db.users.find({"user_id" : {"$in" : [123 




























































































这 会 匹配 "user_id" 等 于 12345 的 文档， 也 会 匹 
配 "user_id" 等 于 "joe" 的 文档 。 


要 是 "$in" 对 应 的 数组 只 有 一 个 值 ， 那 么 和 直接 
匹配 这 个 值 效果 一 样 。 例 如 ，{ticket_no : 
{$in:[725]}} 和 {ticket_no : 725} 的 效果 
样 。 
















































































与 "$in" 相 对 的 是 "$nin"，"$nin" 将 返回 与 数组 
中 所 有 条 件 都 不 匹配 的 文档 。 要 是 想 返 回 所 有 没 
有 中 奖 的 人 ， 就 可 以 用 如 下 方法 进行 查询 : 


> db.raffle.find({"ticket_no" : {"$nin" 

























































































该 查询 会 返回 所 有 没有 中 奖 的 人 。 
"$in" 能 对 单个 键 做 OR 查询 ， 但 要 是 想 找 






































到 "ticket_no" 为 725 或 考 
档 该 怎么 办 呢 ?” 对 于 这 种 









































数组 作为 参数 。 上 面 中 奖 
写 将 是 下 面 这 个 样子 : 























"winner" 为 true 的 文 
青 况 ， 应 该 使 


j"$or"。"$or" 接 受 一 个 包含 所 有 可 能 条 件 的 











的 例子 如 果 用 "$or" 改 








> db.raffle.find({"$or" 


: [{"ticket_no" 








"$or" 可 以 包含 其 他 条 件 。 











例如 ， 如 果 希 望 匹配 





到 中 奖 的 "ticket_no"， 或 者 "winner" 键 的 值 


为 true 的 文档 ， 就 可 以 这 么 做 : 











> db.raffle.find({"$or" 


: [{"ticket_no" 
{"winner" : tru 











使 用 普通 的 AND 型 查询 时 ， 总 是 希望 尽 可 能 用 最 















































少 的 条 件 来 限定 结果 的 范围 。OR 型 查询 正 相反 : 























是 最 为 高 效 的 。 














第 一 个 条 件 应 该 尽 可 能 匹配 更 多 的 文档 ， 这 样 才 





"$or" 在 任何 情况 下 都 会 正常 工作 。 如 果 查 询 优 























化 器 可 以 更 高 效 地 处 理 "$in"， 那 就 选择 使 用 
它 。 


4.2.3 Snot 















































"$not" 是 元 条 件 句 ， 即 可 以 用 在 任何 其 他 条 件 之 








上 。 就 拿 取 模 运算 符 "$mod" 来 说 。 








查询 的 值 除 以 第 一 个 给 定 值 ， 
给 定 值 则 匹配 成 功 : 








"$mod "会 将 





若 余数 等 于 第 二 个 











> db.users.find({"id_num" 


: {"$mod" 


+ [5; 






























































5. 7. 8. 9. 10, 1255 AFA 


























可 "id_num" 值 为 1、6 

的 用 户 。 但 要 是 想 返 回 "id_num" 为 2、3、4、 
户 ey 
’ 就 要 





11、16 等 








> db.users.find({"id_num" 


: {"$not" 


: {"$m 

















"$not "与 正则 表达 式 联 合 使 用 时 极为 有 用 ， 

















细 讲 述 正 则 表达 式 的 使 用 ) 。 





4.2.4 条 件 语义 

















如 果 比 较 一 下 上 一 章 的 更 新 修改 器 和 前 
文档 ， 会 发 现 以 $ 开 头 的 键 位 于 在 不 同 的 











在 查询 中 ，"$1t" 在 内 层 文档 























查找 那些 与 特定 模式 不 匹配 的 文档 (4.3.27 SH 


























来 





而 的 查询 




















》 而 更 新 中 











"$inc" 则 是 外 层 文档 的 键 。 基 本 可 以 肯 




















位 置 。 


条 件 


语句 是 内 层 文档 的 键 ， Ti ALBERS SCR 





键 。 











可 以 对 一 个 键 应 用 多 个 条 件 。 例 如 ， 要 查找 年 龄 
为 20~30 的 所 有 用 户 ， 可 以 在 "age" 键 上 使 
j"$gt" 和 "$1t": 



































> db.users.find({"age" : {"$1t" : 30, "$gt 





























一 个 键 可 以 有 任意 多 个 条 件 ， 但 是 一 个 键 不 能 对 
应 多 个 更 新 [修改 器 。 例如 ， 修 改 器 文档 不 能 同时 
含有 {"$inc" : {"age" : 1}, "$set" : 
{age : 40}}, 因为 修改 了 "age" 两 次 。 但 是 对 
于 查询 条 件 句 就 没有 这 种 限定 。 


有 一 些 “ 元 操作 符 ”(meta-operator) 也 位 于 外 层 
文档 中 ， 比 如 "$and"、"$or" 和 "$nor"。 它 们 的 
使 用 形式 类 似 : 


> db.users.find({"$and" : [{"x" : {"$1t" 

































































这 个 查询 会 匹配 那些 "x" 字 段 的 值 小 于 等 于 1 并 且 
等 于 4 的 文档 。 昌 然 这 两 个 条 件 看 起 来 是 矛盾 
的 ， 但 是 这 是 完全 有 可 能 的 ， 比如 ， 如 果 "x" 字 
段 的 值 是 这 样 一 个 数组 {"x”: [86，4]}， 那 么 
这 个 文档 就 与 查询 条 件 相 匹 配 ， 注意 ， 查 询 优化 
器 不 会 对 "$and "进行 优化 ， 这 与 其 他 操作 符 不 
同 。 如 果 把 上 面 的 查询 改 成 下 面 这 样 ， 效 率 会 更 






























































































































































> db.users.find({"x" : {"$1t" : 1, "$in" 




















4.3 特定 类 型 的 查询 


如 第 2 章 所 述 ，MongoDB 的 文档 可 以 使 用 多 种 类 
型 的 数据 。 其 中 有 一 些 在 查询 时 会 有 特别 的 表 
现 。 



































4.3.1 null 

















null 类 型 的 行为 有 点 奇怪 。 它 确实 能 匹配 自身 ， 
所 以 要 是 有 一 个 包含 如 下 文档 的 集合 : 












































> R n find() 

{' ' : ObjectId("4baefedfd22aa494Fd5236 
{ "_id" : ObjectId("4ba@fedfd22aa494Fd5236 
{' ' : ObjectId("4ba0F148d22aa494Fd5236 

















就 可 以 按照 预期 的 方式 查询 "y" 键 为 nu11 的 文 
档 : 


> db.c.find({"y" : null}) 
{ "_id" : objectId("4baefedfd22aa494fd5236 














但 是 ，nul1 不 仅 会 匹配 某 个 键 的 值 为 nu11 的 文 
档 ， 而 且 还 会 匹配 不 包含 这 个 键 的 文档 。 所 以 ， 

















这 种 匹配 还 会 返回 缺少 这 个 键 的 所 有 文档 : 























> db.c.find({"z" : null}) 

{ "_id" : ObjectId("4ba@fedfd22aa494Fd5236 
{ "_id" : ObjectId("4ba@fedfd22aa494Fd5236 
{ "_id" : ObjectId("4ba@f148d22aa494Fd5236 





























如 果 仅 想 匹 配 键 值 为 nu11 的 文档 ， 既 要 检查 该 键 
的 值 是 否 为 nul1， 还 要 通过 "$exists" 条 件 判定 
键 值 已 存在 : 


> db.c.find({"z" : {"$in" : [null], "$exis 









































很 遗憾 ， 没 有 "$eq" 操 作 符 ， 所 以 这 条 但 询 语句 
看 上 去 有 些 令 人 费解 ， 但 是 使 用 只 有 一 个 元 素 
的 "$in" 操 作 符 效 果 是 一 样 的 。 









































4.3.2 ”正则 表达 式 














FE 则 表达 式 能 够 灵活 有 效 地 匹配 字符 串 。 例 如 ， 
想 要 查找 所 有 名 为 Joe 或 者 joe 的 用 户 ， 就 可 以 使 
j 正 则 表达 式 执行 不 区 分 大 小 写 的 匹配 ; 


> db.users.find({"name" : /joe/i}) 












































p 

















E 


系统 可 以 接受 正则 表达 式 标志 CG) ， 但 不 是 









































定 要 有 。 现 在 已 经 匹配 了 各 利 



































大 小 写 组 合 形式 的 





joe， 如 果 还 希望 匹配 如 "joey" 这 样 的 键 ， 可 以 














略微 修改 一 下 刚刚 的 正则 表达 式 : 








> db.users.find({"name" 


: /joey?/i}) 




















MongoDB 使 用 Perl 兼 容 的 正则 表达 式 CPCRE) Æ 








来 下 配 正则 表达 式 ， 任 何 PCRE 支 持 的 正则 表达 











式 语 法 都 能 被 MongoDB 接 受 。 建 议 在 查询 中 使 
正则 表达 式 前 ， 先 在 JavaScript shell 中 检查 一 下 i 























法 ， 确 保 匹 配 与 设想 的 一 致 。 






































OH + 








an 
“MongoDB 可 以 为 前 级 型 正则 表达 式 

























































































(比如 /^joey/〉 查询 创建 索引 ， 所 以 这 种 类 
型 的 查询 会 非常 高 效 。 
正则 表达 式 也 可 以 匹配 上 虽然 几乎 
接 将 正则 表达 式 插入 到 数据 库 中 ， 但 要 是 万 一 你 
这 么 做 了 ， 也 可 以 匹配 到 自 
> db.foo.insert({"bar" : /baz/}) 
> db.foo.find({"bar" : /baz/}) 


{ 








"_id" : ObjectId("4b23c3ca7525f35f94b6 
"bar" : /baz/ 
} 





4.3.3 ”查询 数组 





查询 数组 元 素 与 查询 标量 值 是 一 样 的 。 例 如 ， 有 
一 个 水 果 列 表 ， 如 下 所 示 : 


> db.food.insert({"fruit" : ["apple", "ban 

















下 面 的 查询 : 


> db.food.find({"fruit" : "banana"}) 


























会 成 功 匹 配 该 文档 。 这 个 查询 好 比 我 们 对 一 个 这 
样 的 (不 合法 ) 文档 进行 查询 : {"fruit" 
"apple", "fruit" : "banana", "fruit" 
"peach"}. 











1. $all 


如 果 需 要 通过 十 多 个 元 素来 匹配 数组 ， 就 要 
j"$all" 了。 这 样 就 会 匹配 一 组 元 素 。 例 如 ， 假 
设 创建 了 一 个 包含 3 个 元 素 的 集合 : 



























































> db.food.insert({"_id" : 1, "fruit" ["a 
> db.food.insert({"_id" : 2, "fruit" : ["a 
> db.food.insert({"_id" : 3, "fruit" ["c 




















要 找到 既 有 "apple" 又 有 "banana'" 的 文档 ， 可 以 
EH" fall" KEM: 
> db.food.find({fruit : {$all : ["apple", 


{"_id" : 1, "fruit" : ["apple", "banan 
{"_id" : 3, "fruit" : ["cherry", "bana 







































































这 里 的 顺序 无 关 紧 要 。 注 意 ， 第 二 个 结果 
"banana" 在 "apple" 之 前 。 要 是 对 只 有 一 个 元 素 
的 数组 使 用 "$all"， 就 和 不 用 "$all" 一 样 了 。 
例如 ，{fruit : {$all : ['apple']} 和 
{fruit : 'apple'} 的 查询 结果 完全 一 样 。 


也 可 以 使 用 整个 数组 进行 精确 匹配 。 但 是 ， 精 确 
匹配 对 于 缺少 元 素 或 者 元 素 元 余 的 情况 就 不 大 灵 
了 。 例 如 ， 下 面 的 方法 会 匹配 之 前 的 第 一 个 文 
档 : 


> db.food.find({"fruit" : ["apple", "banan 















































































































































但 是 下 面 这 个 就 不 会 匹配 : 


> db.food.find({"fruit" : ["apple", "banan 





























这 个 也 不 会 匹配 : 


> db.food.find({"fruit" : ["banana", "appl 




















要 是 想 查 询 数组 特定 位 置 的 元 素 ， 需 使 
jkey .index 语 法 指定 下 标 : 
































> db.food.find({"fruit.2" : "peach"}) 




















数组 下 标 都 是 从 0 开始 的 ， 所 以 上 面 的 表达 式 会 
数组 的 第 3 个 元 素 和 "peach" 进 行 匹配 。 















































2. $size 


"$size" 对 于 查询 数组 来 说 也 是 非常 有 用 的 ， 顾 
名 思 义 ， 可 以 用 它 查 询 特 定 长 度 的 数组 。 例 如 : 






























































> db.food.find({"fruit" : {"$size" : 3}}) 








得 到 一 个 长 度 范围 内 的 文档 是 一 种 常见 的 查 
询 。"$size" 并 不 能 与 其 他 查询 条 件 〈 比 
如 "$gt") 组 合 使 用 ， 但 是 这 种 查询 可 以 通过 在 
文档 中 添加 一 个 "size" 键 的 方式 来 实现 。 这 样 每 
一 次 向 指定 数组 添加 元 素 时 ， 同 时 增加 "size" 的 
值 。 比 如 ， 原 本 这 样 的 更 新 : 






























































> db.food.update(criteria, {"$push" : {"fr 








就 要 变 成 下 面 这 样 : 























> db.food.update(criteria， 
... {"$push" : {"fruit" : "strawberry"}, " 

















自 增 操作 的 速度 非常 快 ， 所 以 对 性 能 的 影响 微 乎 
其 微 。 这 样 存储 文档 后 ， 就 可 以 像 下 面 这 样 查询 
T: 
































> db.food.find({"size" : {"$gt" : 3}}) 











很 遗憾 ， 这 种 技巧 并 不 能 与 "$addToSset" 操 作 符 
同时 使 用 。 























3.$slice 操 作 符 


本 章 前 面 已 经 提 及 ，find 的 第 二 个 参数 是 可 选 
的 ， 可 以 指定 需要 返回 的 键 。 这 个 特别 
的 "$s1lice" 操 作 符 可 以 返回 某 个 键 匹 配 的 数组 
元 素 的 一 个 子 集 。 


例如 ， 假 设 现在 有 一 个 博客 文章 的 文档 ， 我 们 和 希 
望 返回 前 10 条 评论 ， 可 以 这 样 做 : 










































































> db.blog.posts.findOne(criteria, {"commen 


使 









































也 可 以 返回 后 10 条 评论 ， 只 要 在 查询 条 件 
用 -10 就 可 以 了 : 


> db.blog.posts.findOne(criteria, {"commen 


















































"$slice" 也 可 以 指定 偏 移 值 以 及 希望 返回 的 元 
素数 量 ， 来 返回 元 素 集合 中 间 位 置 的 某 些 结果 : 


> db.blog.posts.findOne(criteria, {"commen 










































































这 个 操作 会 跳 过 前 23 个 元 素 ， 返 回 第 24~33 个 元 
素 。 如 果 数 组 不 够 33 个 元 素 ， 则 返回 第 23 个 元 素 
后 面 的 所 有 元 素 。 


除非 特别 声明 ， 否 则 使 用 "$slice" 时 将 返回 文 
档 中 的 所 有 键 。 别 的 键 说 明 符 都 是 默认 不 返回 未 
提 及 的 键 ， 这 点 与 "$slice" 不 太一 样 。 例 如 ， 

有 如 下 博客 文章 文档 : 


{ 




































































”id”: ObjectId("4b2d75476cc613d5ee93 
"title" : "A blog post", 

"content" : "...", 

"comments" : [ 


{ 





"name" : "joe", 


"email" : "joe@example.com", 
"content" : "nice post." 

J 

{ 
"name" : "bob", 
"email" : "bob@example.com", 
"content" : "good post." 

} 























TT 

















1"$slice" 来 获取 最 后 一 条 评论 ， 可 以 这 样 ; 














> db.blog.posts.findOne(criteria, {"commen 


{ 
"_id" : ObjectId("4b2d75476cc613d5ee93 


"title" : "A blog post", 
"content" : "...", 
"comments" : [ 
{ 
"name" : "bob", 
"email" : "bob@example.com", 
"content" : "good post." 
} 
] 











"title" 和 "content" 都 返回 了 ， 即 便 是 并 ; 
































显 式 地 出 现在 键 说 明 符 中 。 
4. 返回 一 个 匹配 的 数组 元 素 






































WRAL TCR Pie, A 























那么 "$slice" 非 常 有 
。 但 有 时 我 们 希望 返回 与 查询 条 件 相 匹配 的 有 





二 

















H 








意 一 个 数组 元 素 。 
配 的 元 素 。 对 于 上 



































可 以 使 用 $ 操 作 符 得 到 一 个 匹 



































四 的 博客 文章 示例 ， 可 以 用 如 
下 的 方式 得 到 Bob 的 评论 : 








} 


> db.blog.posts.find({"comments.name" 


"b 


"comments" : [ 
{ 
"name" : "bob", 
"email" "bob@example.com", 
"content" : "good post." 
} 
] 


"_id" : ObjectId("4b2d75476cc613d5ee93 











注意 ， 这 样 只 会 返 











第 一 个 号 配 的 文档 。 





























Bob 在 这 篇 博客 文章 下 写 过 多 条 评论 ， 只 








有 "comments" 数 组 中 的 第 一 条 评论 会 被 返 








如 





IN 


























5. 数组 和 范围 查询 的 相互 作用 


文档 中 的 标量 〈 非 数组 元 素 ) 必须 与 查询 条 件 中 
e Ee 
{"$gt" : 10, "$lt" : 26}} 进 行 查询 ， 只 会 
TURE" EREA AE 103EH EAE DONT 
档 。 但 是 ， 假 如 某 个 文档 的 "x" 字 段 是 一 个 数 
组 ， 如 果 "x" 键 的 某 一 个 元 素 与 查询 条 件 的 任意 
一 条 语句 相 匹 配 (查询 条 件 中 的 每 条 语句 可 以 
匹配 不 同 的 数组 元 素 ) ， 那 么 这 个 文档 也 会 被 





























































































































下 面 用 一 个 例子 来 详细 说 明 这 种 情况 。 假 如 有 如 
下 所 示 的 文档 : 















































如 果 希 望 找到 "x" 键 的 值 位 于 10 和 20 之 间 的 所 有 
文档 ， 直接 想到 的 查询 方式 是 使 
Jdb.test.find({"x" : {"$gt" : 10, 
"$1t”; 26}})， 希 望 这 个 查询 的 返回 文档 
是 {"x”: 15}。 但 是 ， 实 际 返 回 了 两 个 文档 : 



















































































> db.test.find({"x" : {"$gt" : 10, "$1t" 
{"x" : 15} 
{"x" : [5, 25]} 











5 和 25 都 不 位 于 10 和 20 之 间 ， 但 是 这 个 文档 也 返 
回 了 ， 因 为 25 与 查询 条 件 中 的 第 一 个 语句 (大 于 
10) 相 匹 配 ，5$ 与 查询 条 件 中 的 第 二 个 语句 〈 小 
于 20) 相 匹 配 。 


这 使 对 数组 使 用 范围 查询 没有 用 : 范围 会 匹配 任 
意 多 元 素数 组 。 有 儿 种 方式 可 以 得 到 预期 的 行 


于 先 ， 可 以 使 用 "$elemMatch" 要 求 MongoDB 同 
时 使 用 查询 条 件 中 的 两 个 语句 与 一 个 数组 元 素 进 
行 比较 。 但 是 ， 这 里 有 一 个 问 

题 ,，"$elemMatch" 不 会 匹配 非 数 组 元 素 : 






















































































































































































> db.test.find({"x" : {"$elemMatch" : {"$g 
> // 查 不 到 任何 结果 


{"x”: 15} 这 个 文档 与 查询 条 件 不 再 匹配 了 ， 
寻 为 它 的 "x" 字 上段 是 个 数组 。 

如 果 当 前 查询 的 字段 上 创建 过 索引 (第 5 章 会 讲 
述 索 引 相关 内 容 ) ， 可 以 使 用 min() 和 max() 将 























































































































查询 条 件 遍 历 的 索引 范围 


为 "$gt" 和 "$1t" 的 值 : 








限制 








J 








"x" 





> db.test.find({"x" 


: {"$gt" : 10, "$1t" 





现在 ， 这 个 查询 只 会 遍历 值 位 于 10 和 20 之 间 的 索 
引 ， 不 再 与 5 和 25 进 行 比较 。 只 有 当前 查询 的 字 
段 上 建立 过 索引 时 ， 才 可 以 使 用 min() 和 

max()， 而 且 ， 必 须 为 这 个 索引 的 所 有 字段 指定 



































min() 和 max() 。 


在 可 能 包含 数组 的 文档 上 应 用 范围 查询 时 ， 使 







































































jmin() 和 max() 是 非常 好 的 : 如 果 在 整个 索引 





范围 内 对 数组 使 用 "$gt"/"$1t" 查 询 ， 效 率 是 非 
常 低 的 。 查 询 条 件 会 与 所 有 值 进行 比较 ， 会 查询 





























每 一 个 索引 ， 而 不 仅仅 是 指定 索引 范围 内 的 值 。 


4.3.4 Aim A RIC 














有 两 种 方法 可 以 查询 内 嵌 文 档 ， 查 询 整 个 文档 ， 

















或 者 只 针对 其 键 / 值 对 进行 查询 。 











查询 整个 内 髓 文档 








有 如 下 文档 : 








与 普通 





查询 完全 相同 。 例 如 ， 











name" { 
"first" : "Joe", 
"last" : "Schmoe" 
hs 
"age" 45 








要 查寻 姓名 为 Joe Schmoe 的 人 可 以 这 样 : 


> db.people.find({"name" : {"first" : "Joe 
































但 是 ， 如 果 要 查询 一 个 完整 的 子 文档 ， 那 么 子 文 
档 必 须 精确 匹配 。 如 果 Joe 决 定 添加 一 个 代表 中 间 
名 的 键 ， 这 个 查询 就 不 再 可 行 了 ， 因 为 查询 条 件 
不 再 与 整个 内 内 文档 相 匹 配 。 而 且 这 种 查询 还 是 
与 顺序 相关 的 ，{"1ast" 
"Schmoe", "first" : "Joe"} 什 么 都 匹配 不 
到 。 


如 果 人 允许 的 话 ， 通 常 只 针对 内 嵌 文 档 的 特定 键 值 
进行 查询 ， 这 是 比较 好 的 做 法 。 这 样 ， 即 便 数据 
模式 改变 ， 也 不 会 导致 所 有 查询 因为 要 精确 匹配 
而 一 下 子 都 挂 掉 。 我 们 可 以 使 用 点 表示 法 查询 内 
RIE: 


> db.people.find({"name.first" : "Joe", "n 











































































































































































































现在 ， 如 果 Joe 增 加 了 更 多 的 键 ， 这 个 查询 依然 会 
匹配 他 的 姓 和 名 。 


这 种 点 表示 法 是 查询 文档 区 别 于 其 他 文档 的 主要 
特点 。 EALA NAE RRRA EA A ER 
档 内 部 ”的 意思 。 点 表示 法 也 是 符 插 入 的 文档 不 
能 包含 “.” 的 原因 。 将 URL 作 为 键 保存 时 经 常会 遇 
到 此 类 问题 。 一 种 解决 方法 就 是 在 插入 前 或 者 提 
oe 换 ， 将 “.” 蔡 换 成 一 个 URL 中 

































































































































































当 文 档 结构 变 得 更 加 复杂 以 后 ， 内 嵌 文 档 的 匹配 
需要 些许 技巧 。 例 如 ， 假 设 有 博客 文章 若干 ， 要 
找到 由 Joe 发 表 的 5 分 以 上 的 评论 。 博 客 文章 的 结 
构 如 下 例 所 示 : 


> db.blog.find() 






































{ 
"content" : "...", 
"comments" : [ 
{ 
"author”: "joe", 
"score" : 3, 
"comment" : "nice post" 
}， 


{ 








"author" : "mary", 
"score" : 6, 
"comment" : "terrible post" 


} 








不 能 直接 用 db.blog.find({"comments" : 
{"author" : "joe", "score" : {"$gte" : 
5}}}) 来 查寻 。 内 风 文 档 的 匹配 ， 必 须要 整个 文 
档 完 全 匹配 ， 而 这 个 查询 不 会 匹 
配 "comment" 键 。 使 用 
db.blog.find({"comments.author" : 
"joe", "comments.score" : {"$gte" : 5}} 
也 不 行 ， 因 为 符合 author 条 件 的 评论 和 符 

合 score 条 件 的 评论 可 能 不 是 同一 条 评论 。 也 就 
是 说 ， 会 返回 刚才 显示 的 那个 文档 。 
A"author" : "joe" 在 第 一 条 评论 中 匹配 

J, "score" : 6 在 第 二 条 评论 中 匹配 了 。 


要 正确 地 指定 一 组 条 件 ， 而 不 必 指 定 每 个 键 ， 就 
需要 使 用 "$elemMatch"。 这 种 模糊 的 命名 条 件 
句 能 用 来 在 查询 条 件 中 部 分 指定 匹配 数组 中 的 单 
个 内 航 文 要 。 所 以 正确 的 写法 应 该 是 下 面 这 样 
的 : 



















































































































































































> db.blog.find({"comments" : {"$elemMatch" 























yE 


"$elemMatch" 将 限定 条 件 进行 分 组 ， 仅 当 需 
对 一 个 内 嵌 文 档 的 多 个 键 操 作 时 才 会 用 到 。 








4.4 $where 查 询 


键 / 值 对 是 一 种 表达 能 力 非 常 好 的 查询 方式 ， 但 是 
依然 有 些 需求 它 无 法 表达 。 其 他 方法 都 败 下 阵 
WY, 就 轮 到 "$where" 子 句 登 iy I J> H 它 可 以 在 

查询 中 执行 任意 的 JavaScript。 这 样 就 能 在 查询 中 
fi JLP) 任何 事情 。 为 安全 起 见 ， 应 该 严格 限 
判 或 者 消除 "$where" 语 句 的 使 用 。 应 该 禁止 终 

端 用 户 使 用 任意 的 "$where" 语 句 。 


"$where" 语 句 最 常见 的 应 用 就 是 比较 文档 中 的 
两 个 键 的 值 是 否 相等 。 假 如 我 们 有 如 下 文档 : 


> db.foo.insert({"apple" : 1, "banana" : 6 
> db.foo.insert({"apple" : 8, "spinach" 



























































=> 



















































































我 们 希望 返回 两 个 键 具有 相同 值 的 文档 。 第 二 个 
文档 中 ，"spinach" 和 "watermelon" 的 值 相 
同 ， 所 以 需要 返回 该 文档 。MongoDB 似 乎 从 来 没 
有 提供 过 一 个 $ 条 件 语句 来 做 这 种 查询 ， 所 以 只 
























































jr 




















用 "$where" 子 句 借助 JavaScript 来 完成 了 : 





CC 


台 
K 





> db.foo.find({"$where" : function () { 
.. for (var current in this) { 
for (var other in this) { 
if (current != other && this[c 
return true; 
} 


} 


. return false; 


-})); 









































如 果 函 数 返 回 true， pg aa 部 分 
返回 ; 如 果 为 false， 就 不 返 区 


不 是 非常 必要 时 ， 一 定 要 避免 使 用 "$where" 查 
询 ， 因 为 它们 在 速度 上 要 比 常规 查询 慢 很 多 。 每 
个 文档 都 要 从 BSON 转 换 成 JavaScript 对 象 ， 然 后 
通过 "$where" 表 达 式 来 运行 。 而 且 "$where" 语 
句 不 能 使 用 索引 ， 所 以 只 在 走投无路 时 才 考 

虑 "$where" 这 种 用 法 。 先 使 用 常规 查询 进行 过 
滤 ， 然 后 再 使 用 "$where" 语 句 ， 这 样 组 合 使 用 
可 以 降低 性 能 损失 。 如 果 可 能 的 话 ， 使 
j"$where" 语 句 前 应 该 先 使 用 索引 进行 过 

滤 ，"$where" 只 用 于 对 结果 进行 进一步 过 滤 。 

























































































































































































































































































进行 复杂 查询 的 另 一 种 方法 是 使 用 聚合 工具 ， 第 
7 章 会 详细 介绍 。 

















服务 器 端 脚本 





在 服务 器 上 执行 JavaScript 时 必须 注意 安全 性 。 如 
果 使 用 不 当 ， 服 务 器 端 JavaScript 很 容易 受到 注入 
攻击 ， 与 关系 型 数据 库 中 的 注入 攻击 类 似 。 不 
过 ， 只 要 在 接受 输入 时 遵循 一 些 规则 ， 就 可 以 安 
全 地 使 用 JavaScript。 也 可 以 在 运行 mongod 时 指 
定 --noscripting 选 项 ， 完 全 关闭 JavaScript 的 执 
行 。 
JavaScript 的 安全 问题 都 与 用 户 在 服务 器 上 提供 的 
星 序 相关 。 如 果 和 希望 避免 这 些 风险 ， 那 么 就 要 确 
保 不 能 直接 将 用 户 输入 的 内 容 传递 给 mongod。 例 
如 ， 假 如 你 希望 打印 一 句 “Hello, name”, XEK 
name 是 由 用 户 提 供 的 。 使 用 如 下 所 示 的 
JavaScript 函 数 是 非常 容易 想到 的 ; 






















































































































































































> func = "function() { print('Hello, "+nam 












































的 name 是 一 个 用 户 定义 的 变量 ， 它 可 能 
db.dropDatabase();print(' "这样 
守 串 ， 因 此 ， 上 面 的 代码 会 被 转换 成 如 下 
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> func = "function() { print('Hello, '); d 























如 果 执 行 这 段 代 码 ， 你 的 整个 数据 库 就 会 被 删 
除 ! 


为 了 避免 这 种 情况 ， 应 该 使 用 作 
的 值 。 以 Python 为 例 : 


func = pymongo.code.Code("function() { pri 
{"username": name}) 





























j 域 来 传递 name 


Se 









































现在 ， 数 据 库 会 输出 如 下 的 内 容 ， 不 会 有 任何 风 
险 : 


Hello, '); db.dropDatabase(); print('! 












































由 于 代码 实际 上 可 能 是 字符 串 和 作用 域 的 混合 
体 ， 所 以 大 多 数 驱 动 程序 都 有 一 种 特殊 类 型 ， 用 
于 向 数据 库 传递 代码 。 作 用 域 是 用 于 表示 变量 名 
和 值 的 映射 的 文档 。 对 于 要 被 执行 的 JavaScript 函 
数 来 说 ， 这 个 映射 就 是 一 个 局 部 作用 域 。 因 此 ， 
在 上 面 的 例子 中 ， 函 数 可 问 username 这 个 
变量 ， 这 个 变量 的 值 就 是 用 户 传 进来 的 字符 







































































































































































Ph 没 有 包含 作用 域 的 代码 类 
型 ， 所 以 作 TBA HE TE TIFE BR JavaScript ex 
数 中 使 用 。 






































4.5 游标 





























数据 库 使 用 游标 返回 find 的 执行 结果 。 客 户 端 对 
游标 的 实现 通常 能 够 对 最 终结 果 进 行 有 效 的 控 
制 。 可 以 限制 结果 的 数量 ， 略 过 部 分 结果 ， 根 据 
任意 键 按 任 意 顺 序 的 组 合 对 结果 进行 各 种 排序 ， 

或 者 是 执行 其 他 一 些 强大 的 操作 。 


要 想 从 shell 中 创建 一 个 游标 ， 首 先 要 对 集合 填充 
一 些 文档 ， 然 后 对 其 执行 查询 ， 并 将 结果 分 配给 
一 个 局 部 变量 (用 var 声 明 的 变量 就 是 局 部 变 
量 ) 。 这 里 ， 先 创建 一 个 简单 的 集合 ， 而 后 做 个 
查询 ， 并 用 cursor 变 量 保存 结果 : 


> for(i=6;j i<100; i++) { 
db.collection.insert({x : i}); 
- I 


> var cursor = db.collection.find(); 




























































































































































































































































































这 么 做 的 好 处 是 可 以 一 次 查看 一 条 结果 。 如 果 将 
结果 放 在 全 局 变量 或 者 就 没有 放 在 变量 中 ， 
MongoDB shell 2 Fi aiis ft, 自动 显示 最 开始 的 若 
二 文档 。 也 就 是 在 这 之 前 我 们 看 到 的 种 种 例子 ， 
一 般 大 家 只 想 通过 shell 看 看 集合 里 面 有 什么 ， 而 
不 是 想 在 其 中 实际 运行 程序 ， 这 样 设计 也 就 很 合 
适 。 


要 迭代 结果 ， 可 以 使 用 游标 的 next 方 法 。 也 可 以 
使 用 hasNext 来 查看 游标 中 是 否 还 有 其 他 结果 。 
典型 的 结果 遍历 如 下 所 示 : 


















































































































































































































































> while (cursor.hasNext()) { 
obj = cursor.next(); 
// do stuff 





- } 


cursor.hasNext() 检 查 是 否 有 后 续 结果 存在 ， 
然后 用 cursor .next() 获 得 它 。 






































游标 类 还 实现 了 JavaScript 的 迭代 器 接口 ， 所 以 可 
以 在 forEach 循 环 中 使 用 : 


























> var cursor = db.people.find(); 
> cursor.forEach(function(x) { 
print(x.name) ; 


de 
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matt 
zak 








调 月 














待 真正 开 
执行 之 前 可 
对 象 的 每 个 
任意 顺序 组 
价 的 : 























以 给 查询 附 放 
方法 者 
成 方法 











0 额外 的 选项 。 





kE. Wun, 


返回 游标 本 身 ， 这 检 


有 find 时 ，shell 并 不 立即 查询 数据 库 ， 而 是 等 


台 要 求 获得 结果 时 才 发 送 查 询 ， 这 档 


在 
几乎 游标 





lL 就 可 以 按 














下 面 几 利 











表达 是 等 








> var cursor 
> var cursor 
> var cursor 


db.foo.find().sort({"x" 
db.foo.find().limit(1).sort 
db.foo.find().skip(10).limi 


: 1 








此 时 ， 查 询 








是 构造 查询 。 














还 没有 真正 执行 ， 所 有 这 些 函 数 都 只 
现在 ， 假 设 我 们 执行 如 下 操作 : 
































> cursor.hasNext() 








这 时 ， 查 询 











被 发 往 月 
































前 4 MB 数据 

















及 务 器 。 


或 者 hasNext 时 就 
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RT. 各 
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HgetMo 





shell 立 刻 获取 前 100 
较 小 者 ) ， 这 
不 必 再 次 连接 
Jé J 第 一 组 结果 ， 

次 联系 数据 库 ， 使 有 
getMore 请 求 包含 一 个 查询 标识 
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青 求 提 
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向 数据 库 询问 是 否 还 有 更 多 的 结果 ， 如 果 





有 ， 则 返 
游标 





4.5.1 


























则 返回 下 一 批 结果 。 这 个 过 程 会 一 直 持续 到 









































OS 或 者 结果 全 部 返 Bl, 








limit, skip#llsort 














用 的 查询 选项 就 是 限制 返 区 











结果 的 数量 、 忽 
































HX 
Hg 
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要 在 





查询 被 发 送 到 服务 器 之 前 指 























要 限 
例如 
































定数 量 的 结果 以 及 排序 。 所 有 这 些 选项 一 定 
定 。 


制 结果 数量 ， 可 在 find 后 使 用 1imit 函 数 。 














, 只 返回 3 个 结果 ， 可 以 这 文 样 : 

















> db.c.find().1imit(3) 














ARE 


果 。 


是 匹配 的 结果 不 到 3 个 ， 则 返 














H 








匹配 数量 的 结 





1imit 指 定 的 是 上 限 ， 而 非 下 限 。 


skip 与 1imit 类 似 : 





> db.c.find().skip(3) 


上 面 
余下 
个 9 











的 操作 会 略 过 前 三 个 匹配 的 文档 ， 然 后 返 下 
































的 文档 。 如 果 集 合 里 面 能 匹配 的 文档 少 于 3 














则 不 会 返回 任何 文档 。 


























sort 接 受 一 个 对 象 作为 参数 ， 这 个 对 象 是 一 组 
键 / 值 对 ， 键 对 应 文档 的 键 名 ， 值 代表 排序 的 方 
向 。 排 序 方向 可 以 是 1 (升序 ) 或 者 -1 (降序) 。 
如 果 指 定 了 多 个 键 ， 则 按照 这 些 键 被 指定 的 顺序 
逐个 排序 。 例 如 ， 要 按照 "username" 升 序 
Rage" 降序 排 序 ， 可 以 这 样 写 : 






































> db.c.find().sort({username : 1, age : -1| 

















这 3 个 方法 可 以 组 合 使 用 。 这 对 于 分 页 非常 有 
。 例 如 ， 你 有 个 在 线 商店 ， 有 人 想 搜索 mp3 。 
若是 想 每 页 返回 50 个 结果 ， 而 且 按 照 价 格 从 高 到 
低 排序 ， 可 以 这 样 写 : 



























































> db.stock.find({"desc" : "mp3"}).limit(50 





























点 击 “ 下 一 页 ”可 以 看 到 更 多 的 结果 ， 通 过 skip 也 
可 以 非常 简单 地 实现 ， 只 需要 略 过 前 50 个 结果 就 
好 了 (已经 在 第 一 页 显示 了 ) : 












































> db.stock.find({"desc" : "mp3"}).limit(50 














然而 ， 略 过 过 多 的 结果 会 导致 性 能 问题 ， 下 一 小 
市 会 讲述 如 何 避 免 略 过 大 量 结果 。 


比较 顺序 
































MongoDB 处 理 不 同类 型 的 数据 是 有 一 定 顺 序 的 。 
有 时 一 个 键 的 值 可 能 是 多 种 类 型 的 ， 例 如 ， 整 型 
和 布尔 型 ， 或 者 字符 串 和 nul1。 如 果 对 这 种 混合 
类 型 的 键 排序 ， 其 排序 顺序 是 预先 定义 好 的 。 优 
先 级 从 小 到 大 ， 其 顺序 如 下 : 

. 最 小 值 ; 


数字 ( 整 型 、 长 整 型 、 双 精度 ); 
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4.5.2 ”避免 使 用 skip 略 过 大 量 结果 























jskip 略 过 少量 的 文档 还 是 不 错 的 。 但 是 要 是 数 
量 非 常 多 的 话 ，skip 就 会 变 得 很 慢 ， 因 为 要 先 找 
到 需要 被 略 过 的 数据 ， 然 后 再 抛弃 这 些 数 据 。 7 
多 数 数据 库 都 会 在 索引 中 保存 更 多 的 元 数据 ， 







































































于 处 理 skip， 但 是 MongoDB 目 前 还 
要 尽量 避免 略 过 太 多 的 数据 。 通 常 可 以 利用 上 次 
































的 结果 来 计算 下 








1. AA skipxt 4 
最 简单 的 分 页 方法 














页 ， 然 后 将 每 个 后 续 允 























量 返回 。 











:不 支持， 所 以 








次 查询 条 件 。 
吉 果 分 页 


就 是 用 1imit 返 回 结 果 的 第 一 
页 面 作为 相对 于 开始 的 偏 移 



























































> // 不 要 这 么 用 : 
> var pagel 








> var page3 








略 过 的 数据 比较 多 时 ， 速 度 会 变 第 


= db.foo.find(criteria) .limit( 
> var page2 = db.foo.find(criteria).skip(1 
= db.foo.find(criteria).skip(2 








然而 ， 一 般 来 讲 可 











以 找到 一 种 方法 在 不 使 用 skip 





的 情况 下 实现 分 页 


， 这 取决 于 查询 本 身 。 例 如 ， 









































式 获 取 结 果 的 第 





要 按照 "date" 降 序 显 示 文 档 列 表 。 可 以 用 如 下 方 


页 


Ne 








> var pagel = db.foo.find().sort({"date" 




















然后 ， 可 以 利用 最 
查询 条 件 ， 来 获取 





























后 一 个 文档 中 "date" 的 值 作为 
下 一 页 : 








[var latest = null; | 


// 显示 第 一 页 
while (page1.hasNext()) { 
latest = pagel.next(); 











display(latest) ; 
// 获取 下 一 页 
var page2 = db.foo.find({"date" : {"$gt" 
page2.sort({"date" : -1}).limit(100); 





这 样 查询 中 就 没有 skip 了 。 
2. 随机 选取 文档 


从 集合 里 面 随机 挑选 一 个 文档 算是 个 常见 问题 。 

最 笨 的 〈 也 很 慢 的 ) 做 法 就 是 先 计 算 文档 总 数 ， 

然后 选择 一 个 从 0 到 文档 数量 之 间 的 随机 数 ， 利 

jfind 做 一 次 查询 ， 略 过 这 个 随机 数 那 么 多 的 文 

档 ， 这 个 随机 数 的 取 值 范围 为 0 到 集合 中 文档 的 
总 数 : 


> // 不 要 这 么 用 
> var total = db.foo.count() 

> var random = Math.floor(Math.random()*to 
> db. foo.find().skip(random) .limit(1) 






































































































































这 种 选取 随机 文档 的 做 法 效率 太 低 : 首先 得 计算 














总 数 〈 要 是 有 查询 条 件 就 会 很 费时 ) ， 然 后 
jskip 略 过 大 量 结果 也 会 非常 耗 时 。 










































































略微 动 动脑 筋 ， 从 集合 里 面 查 找 一 个 随机 元 素 还 
是 有 好 得 多 的 办 法 的 。 秘 诀 就 是 在 插入 文档 时 给 
每 个 文档 都 添加 一 个 额外 的 随机 键 。 例 如 在 shell 
中 ， 可 以 用 Math.random() (产生 一 个 0~1 的 随 
机 数 ) : 












































> db.people.insert({"name" : "joe", "rando 
> db.people.insert({"name" : "john", "rand 
> db.people.insert({"name" : "jim", "rando 

















这 样 ， 想 要 从 集合 中 查找 一 个 随机 文档 ， 只 要 计 
算 一 个 随机 数 并 将 其 作为 查询 条 件 就 好 了 ， 完 全 
不 用 skip: 


























> var random = Math.random() 
> result = db.foo.findOne({"random" : {"$g 




















偶尔 也 会 遇 到 产生 的 随机 数 比 集合 中 所 有 随机 值 
都 大 的 情况 ， 这 时 就 没有 结果 返回 了 。 遇 到 这 种 
情况 ， 那 就 将 条 件 操作 符 换 一 个 方向 : 


> if (result == null) { 
= result = db.foo.findOne({"random" 
- 3 


























































































































要 是 集合 里 面 本 就 没有 文档 ， 则 会 返回 nu11， 这 
说 得 通 。 























这 种 技巧 还 可 以 和 其 他 各 种 复杂 的 查询 一 同 使 
， 仅 需要 确保 有 包含 随机 键 的 索引 即 可 。 例 
如 ， 想 在 加 州 随机 找 一 个 水 暖 工 ， 可 以 

对 "profession"、"state" 和 "random" 建 立 索 


al 















































> db.people.ensureIndex({"profession" : 1, 























这 样 就 能 很 快 得 出 一 个 随机 结果 (关于 索引 ， 详 
MARSE) o 














45.3 ”高 级 查询 选项 
































有 两 种 类 型 的 查询 : 简单 查询 (plain query) 和 
封装 查询 (wrapped query) 。 简 单 查 询 就 像 下 面 
这 样 : 














> var cursor = db.foo.find({"foo" : "bar"} 











有 一 些 选项 可 以 用 于 对 查询 进行 “封装 *。 例 如 ， 
假设 我 们 执行 一 个 排序 : 

















> var cursor = db.foo.find({"foo" : "bar"} 

















实际 情况 不 是 将 {"foo”: "bar"} 作 为 查询 直接 
发 送 给 数据 库 ， 而 是 先 将 查询 封装 在 一 个 更 大 的 
文档 中 。shell 会 把 查询 从 {"foo”: "bar"} 转 换 
成 {"$query” : {"foo" 

"bar"}, "$orderby" : {"x" : 1}}. 


绝 大 多 数 驱 动 程序 都 提供 了 辅助 函数 ， 用 于 向 查 
询 中 添加 各 种 选项 。 下 面 列举 了 其 他 一 些 有 用 的 


选项 。 


































































































e $maxscan : integer 


旨 定 本 次 查询 中 扫描 文档 数量 的 上 限 。 


> db.foo.find(criteria). addSspecial("$ 









































如 果 不 希 望 查 询 耗 时 太 多 ， 也 不 确定 集合 中 
到 底 有 多 少 文档 需要 扫描 ， 那 么 可 以 使 用 这 
个 选项 。 这 样 就 会 将 查询 结果 限定 为 与 被 扫 
描 的 集合 部 分 相 匹配 的 文档 。 这 种 方式 的 一 
个 坏处 是 ， 茶 些 你 希望 得 到 的 文档 没有 扫描 
到 。 













































































$min : document 

查询 的 开始 条 件 。 在 这 样 的 查询 中 ， 文 档 必 
须 与 索引 的 键 完 全 匹配 。 查 询 中 会 强制 使 用 
给 定 的 索引 。 



















































































在 内 部 使 用 时 ， 通 常 应 该 使 用 "$gt" 代 
"$min"。 可 以 使 用 "$min" 强 制 指定 一 次 
索引 扫描 的 下 边界 ， 这 在 复杂 查询 中 非常 有 
| 







































































$max : document 

查询 的 结束 条 件 。 在 这 样 的 查询 中 ， 文 档 必 
须 与 索引 的 键 完全 匹配 。 查 询 中 会 强制 使 用 
给 定 的 索引 。 
在 内 部 使 用 时 ， 通 常 应 该 使 用 "$1g" 而 不 
是 "$max"。 可 以 使 用 "$max" 强 制 指定 一 次 
索引 扫描 的 上 边界 ， 这 在 复杂 查询 中 非常 有 
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$showDiskLoc : true 
在 查询 结果 中 添加 一 个 "$diskLoc" 字 段 ， 
用 于 显示 该 条 结果 在 磁盘 上 的 位 置 。 例 如 ， 
































> db.foo.find()._addSpecial('$showDisk 
{ "_id" : ©, "$diskLoc" : { "file" : 2 
{ "_id" : 1, "$diskLoc" : { "file" : 2 
































文件 号 码 显 示 了 这 个 文档 所 在 的 文件 。 如 果 
这 里 使 用 的 是 test 数 据 库 ， 那 么 这 个 文档 就 在 
test.2 文 件 中 。 第 二 个 字段 显示 的 是 该 文档 在 
文件 中 的 偏 移 量 。 









































4.5.4 获取 一 致 结果 














数据 处 理 通常 的 做 法 就 是 先 把 数据 从 MongoDB 中 
取出 来 ， 然 后 做 一 些 变换 ， 最 后 再 存 回去 ; 


cursor = db.foo.find(); 





























while (cursor.hasNext()) { 
var doc = cursor.next(); 
doc = process(doc) ; 
db.foo.save(doc); 








} 


结果 比较 少 ， 这 样 是 没 问 题 的 ， 但 是 如 果 结 果 集 
比较 大 ，MongoDB 可 能 会 多 次 返回 同一 个 文档 。 
为 什么 呢 ? 想象 一 下 文档 究竟 是 如 何 存储 的 吧 。 
可 以 将 集合 看 做 一 个 文档 列表 ， 如 图 4-1 所 示 。 雪 








ny 














花 代表 文档 ， 因 为 每 一 个 文档 都 是 美丽 且 唯 一 














图 4-1 FAW MRA 


这 样 ， 进 行 查找 时 ， 从 集合 的 开头 返回 结果 ， 游 
标 不 断 向 右 移 动 。 程 序 获取 前 100 个 文档 并 处 
理 。 将 这 些 文档 保存 回 数 据 库 时 ， 如 果 文 档 体 积 
增加 了 ， 而 预 留 空 间 不 足 ， 如 图 4-2 所 示 ， 这 时 就 
需要 对 体积 增 大 后 的 文档 进行 移动 。 通 常会 将 它 
们 挪 至 集合 的 末尾 处 〈 如 图 4-3 所 示 ) 。 





































































































图 4-2 ”体积 变 大 的 文档 ， 可 能 无 法 保存 回 原先 


的 位 置 


eo 0w 








图 4-3 ”MongoDB 会 为 更 新 后 无 法 放 回 原 位 置 
的 文档 重新 分 配 存储 空间 


现在 ， 程 序 继续 获取 大 量 的 文档 ， 如 此 往复 。 当 
游标 移动 到 集合 末尾 时 ， 就 会 返回 因 体积 太 大 无 
法 放 回 原 位 置 而 被 移动 到 集合 末尾 的 文档 ， 如 图 
4-4 所 示 。 






























































图 4-4 游标 可 能 会 返回 那些 由 于 体积 变 大 而 被 
移动 到 集合 末尾 的 文档 


应 对 这 个 问题 的 方法 就 是 对 查询 进行 快照 
(snapshot) 。 如 果 使 用 了 这 个 选项 ， 查 询 就 

在 "id" 索 引 上 遍历 执行 ， 这 样 可 以 保证 每 个 文 

档 只 被 返回 一 次 。 例 如 ， 将 db.foo.find() 改 











N 








> db.foo.find().snapshot() 





快照 会 使 查询 变 慢 ， 所 以 应 该 只 在 必要 时 使 用 快 








照 。 例 如 ，mongodump () 


绍 ) 默认 在 快照 上 使 























所 有 返回 单 批 结果 的 查询 都 被 有 效 地 进行 了 快 
照 。 当 游标 正在 等 待 获取 下 















































] 于 备份 ， 
查询 。 


第 22 章 会 介 























一 批 结 果 时 ， 如 果 引 





aor 








合 发 生 了 变化 ， 数 据 才 可 能 





4.5.5 游标 生命 周期 











看 待 游标 有 两 种 角 / 





出 现 不 一 致 。 





度 : APY 





端的 游标 以 及 客户 端 





游标 表示 的 数据 库 游 标 。 
的 游标 ， 接 下 来 简要 看 看 服务 器 端 发 生 了 什么 。 


端 ， 游 标 消 耗 内 存 和 





在 服务 器 端 








前 

















面 讨论 的 都 是 客户 端 











[其 他 资源 。 游 标 换 








历尽 ] FARN, REEN MERIH aR 








止 ， 数 据 库 将 会 





符 放 这 些 
被 数据 库 男 作 他 用 ， 这 是 非 


< 资源。 释放 的 资源 可 以 





常 有 益 的 ， 所 以 要 尽 








量 保证 尽快 释放 游标 《在 合 











情况 导 
先 ， 游 标 完 成 匹配 结 




















区 游标 





, 如 果 客 户 端 
本， 驱动 程序 会 向 服务 器 发 ; 




















理 的 前 提 下 ) 。 





终止 《随后 被 清理 ) 。 首 
的 迭代 时 ， 它 会 ; 
的 游标 已 经 不 在 作用 二 





























除 




















内 
送 一 条 特别 的 消息 ， 






































让 其 销毁 游标 。 




















IPRA RREA 















































在 10 分 钟 内 没有 使 ) 





结果 ， 并 且 游 标 也 还 在 作 |/ 











用 域 中 ， 如 果 
的 话 ， 数 据 库 游 标 也 会 自动 




















个 游标 























销毁 。 这 样 的 话 ， 如 果 客 户 端 崩溃 下 或 者 出 错 ， 
MongoDB 就 不 需要 维护 这 上 千 个 被 打开 却 不 再 使 
的 游标 。 


这 种 “超时 销毁 ”的 行为 是 我 们 希望 的 : 极 少 有 应 
程序 希望 用 户 花 费 数 分 钟 坐 在 那里 等 待 结 果 。 
然而 ， 有 了 时 的 确 希 望 游标 持续 的 时 间 长 一 些 。 符 
是 如 此 的 话 ， 多 数 驱 动 程序 都 实现 了 一 个 叫 
immortal 的 函数 ， 或 者 类 似 的 机 制 ， 来 告知 数 
据 库 不 要 让 游标 超时 。 如 果 关 闭 了 游标 的 超时 时 
间 ， 则 一 定 要 迭代 完 所 有 结果 ， pee enn 
毁 ， 以 确保 游标 被 关闭 。 否 则 它 会 一 直 在 数据 库 
中 消耗 服务 器 资源 。 


4.6 ”数据 库 命令 


有 一 种 非常 特殊 的 查询 类 型 叫 作 数 据 库 命令 

(database command) 。 前 面 已 经 介绍 过 文档 的 
创建 、 更 新 、 删 除 以 及 查询 。 这 些 都 是 数据 库 命 
令 的 使 用 范畴 ， 包 括 管理 性 的 任务 (比如 关闭 服 
务 器 和 克隆 数据 库 、 统 计 集 合 内 的 文档 数量 以 
及 执行 聚合 等 。 


本 节 主 要 讲述 数据 库 命令 ， 在 数据 操作 、 管 理 以 
及 监控 中 ， 数 据 库 命令 都 是 非常 有 用 的 。 例 如 ， 
删除 集合 是 使 用 "drop" 数 据 库 命令 完成 的 : 









































































































































































































































































































































> db.runCommand({"drop" : "test"}); 
{ 


"nIndexesWas" : 1, 

"msg" : “indexes dropped for collectio 
"ns" : "test.test", 

"ok" : true 





} 


也 许 你 对 shell 辅 助 函 数 比 较 熟 悉 ， 这 些 辅助 函数 
封装 数据 库 命 令 ， 并 提供 更 加 简单 的 接口 : 


> db.test.drop() 































































































通常 ， 只 使 用 shell 辅 助 函数 就 可 以 了 ， 但 是 了 解 
它们 底层 的 命令 很 有 帮助 。 尤 其 是 当 使 用 旧版 本 
的 shell 连 接 到 新 版 本 的 数据 库 上 时 ， 这 个 shell 可 
能 不 支持 新 版 数据 库 的 一 些 命令 ， 这 时 候 就 不 得 
不 直接 使 用 runCommand()。 


在 前 面 的 章节 中 已 经 看 到 过 一 些 命 令 了 ， 比 如 ， 
第 3 章 使 用 getLastError 来 查看 更 新 操作 影响 到 
的 文档 数量 : 


> db.count.update({x : 1}, {$inc : {x : 1} 
> db.runCommand({getLastError : 1}) 


{ 





























































































































"err" : null, 


"updatedExisting" : true, 
"A" :5, 
"ok" : true 


} 








AST 2 RATT BBG tS, RA IK 
些 数据 库 命令 令 到 底 是 什么 到 底 是 怎么 实现 的 。 


















































节 也 会 介绍 MongoDB 提 供 的 些 非常 有 的 命 





令 。 人 人 listCommands() 可 以 看 到 








所 有 的 数据 库 命 令 。 

















数据 库 命令 工作 原理 














数据 库 命令 总 会 返回 一 个 包含 "ok" 键 的 文档 。 如 














果 "ok" 的 值 是 1， 说 明 命令 执行 成 功 了 ; 
是 0， 说 明 F= 些 原因 , 命令 执行 失败 。 












































如 果 值 











如 果 "ok" 的 值 是 9， 那 么 命令 的 返回 文档 中 就 会 










































































有 一 个 额外 的 键 "errmsg"。 它 的 值 是 一 个 字符 
串 ， 用 于 描述 命令 的 失败 原因 。 例 如 ， 如 果 试 着 





在 上 一 节 已 经 删除 的 集合 上 再 次 执行 drop 命 令 : 














> db.runCommand({"drop" : "test"}); 
{ "errmsg" : "ns not found", "ok" 





: false 














MongoDB 中 的 命令 被 实现 为 一 种 特殊 类 型 








4 的 查 








询 ， 这 些 特殊 的 查询 会 在 $cmd 集 合 上 执 

行 。runCommand 只 是 接受 一 个 命令 文档 ， 并 且 
执行 与 这 个 命令 文档 等 价 的 查询 。 于 是 ，drop 命 
令 会 被 转换 为 如 下 代码 : 


db.$cmd.findOne({"drop" : "test"}); 












































当 MongoDB 服 务 器 得 到 一 个 在 $cmd 集 合 上 的 查询 
时 ， 不 会 对 这 个 查询 进行 通常 的 查询 处 理 ， 而 是 
会 使 用 特殊 的 逻辑 对 其 进行 处 理 。 几 乎 所 有 的 
MongoDB 驱 动 程序 都 会 提供 一 个 类 
以 runCommand 的 辅助 函数 ， 用 于 执行 命令 ， 而 
且 命 令 总 是 能 够 以 简单 查询 的 方式 执行 。 
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有 些 命令 需要 有 管理 员 权 限 ， 而 且 要 在 admin 数 
据 库 上 才能 执行 。 如 果 在 其 他 数据 库 上 执行 这 样 
的 命令 ， 就 会 得 到 一 个 "access denied" (访问 
被 拒绝 ) 错误 。 如 果 当 前 位 于 其 他 的 数据 库 ， 但 
是 需要 执行 一 个 管理 员 命 令 ， 可 以 使 
jadminCommand 而 不 是 runCommand: 
































































































































> use temp 

switched to db temp 

> db.runCommand({shutdown:1}) 

{ "errmsg" : "access denied; use admin db" 
> db.adminCommand({"shutdown" : 1}) 























MongoDB 中 ， 数 据 库 命令 是 少数 与 字段 顺序 相关 
的 地 方 之 一 : 命令 名 称 必 须 是 命令 中 的 第 一 个 字 
Be. Alt, {"getLastError" : 1, "w" : 2} 
是 有 效 的 命令 ， 而 {"w"” : 2, "getLastError" 
: 1} 不 是 。 


























设计 应 用 


第 S$ 章 ”索引 


本 章 介绍 MongoDB 的 索引 ， 索 引 可 以 用 来 优化 查 
询 ， 而 且 在 某 些 特定 类 型 的 查询 中 ， 索 引 是 必 不 
可 少 的 。 


么 是 索引 ? 为 什么 要 用 索引 ? 

上 何 选择 需要 建立 索引 的 字段 ? 

[ 何 强制 使 用 索引 ? 如 何 评估 索引 的 效率 ? 
| 建 索 引 和 删除 索引 。 


为 集合 选择 合适 的 索引 是 提高 性 能 的 关键 。 
51 索引 简介 


数据 库 索引 与 书籍 的 索引 类 似 。 有 了 索引 就 不 需 
要 翻 整 本 书 ， 数 据 库 可 以 直接 在 索引 中 查找 ， 在 
索引 中 找到 条 目 以 后 ， 就 可 以 直接 跳 转 到 目标 文 
档 的 位 置 ， 这 能 使 查找 速度 提高 几 个 数量 级 。 


不 使 用 索引 的 查询 称 为 全 表 扫 描 《〈 这 个 术语 来 上 
关系 型 数据 库 ) ， 也 就 是 说 ， 服 务 器 必须 查找 完 
一 整 本 书 才能 找到 查询 结果 。 这 个 处 理 过 程 与 我 
们 在 一 本 没有 索引 的 书 中 碍 找 信息 很 像 ， 从 第 1 
页 开始 一 直 读 完整 本 书 。 通 常 来 说 ， 应 该 尽量 避 
免 全 表 扫 描 ， 因 为 对 于 大 集合 来 说 ， 全 表 扫 描 的 
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效率 非常 低 。 





























来 看 一 个 例子 ， 我 们 创建 一 个 拥有 1 000 000 个 
KX 档 的 集合 (如 果 你 想 要 10 000 000 或 者 100 000 
000 个 文档 也 行 ， 只 要 你 有 那个 耐心 ) 






































> for (i=0; i<1000000; i++) { 
sass db.users.insert( 


{ 
pe eee 
"username" : "user"+i, 
"age" : Math.floor(Math.ra 
"created" : new Date() 

} 


J 





i 















































如 果 在 这 个 集合 上 做 查询 ， 可 以 使 用 explain() 
函数 查看 MongoDB 在 执行 查询 的 过 程 中 所 做 的 导 
情 。 下 面试 着 查询 一 个 随机 的 用 户 名 : 






































是 









































> db.users.find({username: "user101"}).exp 
{ 
"cursor" : "BasicCursor", 
"nscanned" : 1000000, 
"nscannedObjects" : 1000000, 
"n" : 1, 
"millis" : 721, 





"nYields" : 6， 
"nChunkSkips" : 0, 
"isMultikey" : false, 
"indexOnly" : false, 
“indexBounds" : { 








} 


5.2 节 会 详细 介绍 输出 信息 里 的 这 些 字 段 ， 目 前 来 
说 可 以 忽略 大 多 数字 段 。 "nscanned" 是 
MongoDB 在 完成 这 个 查询 的 过 程 中 扫描 的 文档 总 
数 。 可 以 看 到 ， 这 个 集合 中 的 每 个 文档 都 被 扫描 
过 了 。 也 就 是 说 ， 为 了 完成 这 个 查询 ， MongoDB 
查看 了 每 一 个 文档 中 的 每 一 个 字段 。 这 个 查询 耗 
费 了 将 近 1 秒 的 时 间 才 完成 : "mil1is" 字 段 显示 
的 是 这 个 查询 耗费 的 毫秒 数 。 


字段 "n" 显 示 了 查询 结果 的 数量 ， 这 里 是 1， 因 为 
这 个 集合 中 确实 只 有 一 个 username 

为 "user161" 的 文档 。 注 意 ， 由 于 不 知道 集合 里 
的 username 字 段 是 唯一 的 ，MongoDB 不 得 不 查 
看 集合 中 的 每 一 个 文档 。 为 了 优化 查询 ， 将 查询 
结果 限制 为 1， 这 样 MongoDB 在 找到 一 个 文档 之 
后 就 会 停止 了 : 


[> db.users.find({username: "user101"}).lim 





























































































































































































































"cursor" : "BasicCursor", 
"nscanned" : 102, 
"nscannedObjects" : 102, 
"aN xe. Ly 

"millis" : 2, 


"nYields" : 0, 
"nChunkSkips" : 0, 
"isMultikey" : false, 
"indexOnly" : false, 
"indexBounds" : { 


} 











现在 ， 所 扫描 的 文档 数量 极 大 地 减少 了 ， 而 且 整 
查询 几乎 是 瞬间 完成 的 。 但 是 ， 这 个 方案 是 不 
现实 的 : 如 果 要 查找 的 是 user999999 呢 ? 我 们 
仍然 不 得 不 遍历 整个 集合 ， 而 且 ， 随 着 用 户 的 增 
加 ， 查 询 会 越 来 越 慢 。 


对 于 此 类 查询 ， 索 引 是 一 个 非常 好 的 解决 方案 : 

索引 可 以 根据 给 定 的 字段 组 织 数据 ， 让 MongoDB 
能 够 非常 快 地 找到 目标 文档 。 下 面 尝试 

em ol 




















FE 



































































































































> db.users.ensureIndex({"username" : 1}) 





























由 于 机 器 性 能 和 集合 大 小 
能 需要 花 几 分 钟 时 间 。 如 
] 没 能 在 几 秒 钟 后 返回 ， 


























y 








查看 索引 创建 的 进度 。 

















Jdb.currentOp() 或 者 是 检查 mongod 的 日 








的 不 同 ， 创 建 索引 有 可 
果 对 ensureIndex 的 调 
口 


可 以 在 另 一 个 shell 中 执 
志 来 






































创建 











AY 成 之 后 ， 





次 


Iu 





执行 最 初 的 查询 : 








> db.users.find({"username" 


{ 
"cursor" 
"nscanned" : 1, 
"nscannedObjects" 
"n" 2 1, 
"millis" : 3, 
"nYields" : 0, 
"nChunkSkips" : 
“isMultikey" 
"indexOnly" 
"indexBounds" 

"username" 


[ 


©, 


:{ 
: [ 


"user101" 


"user101"}). 


"BtreeCursor username_1", 


et 


: false, 
: false, 


3 


"user101" 














这 次 explain() 的 输出 内 容 比 之 前 复杂 一 些 ， 但 
是 目前 我 们 只 需要 注 

mn", oo :和 "mi11is" 这 几 个 字段 ， 
可 以 忽略 其 他 字段 。 可 以 看 到 ， 这 个 查询 现在 几 
乎 是 瞬间 完成 的 ， 而 且 对 于 任 
意 username 的 查询 ， 所 耗费 的 时 间 基 本 一 致 : 



































> db.users.find({username: "user999999"}). 
1 























可 以 看 到 ， 使 用 了 索引 的 查询 几乎 可 以 瞬间 完 
成 ， 这 是 非常 激动 人 心 的 。 然 而 ， 使 用 索引 是 有 
代价 的 ， 对 于 添加 的 每 一 个 索引 ， 每 次 写 操作 
《插入 、 更 新 、 删 除 ) 都 将 耗费 更 多 的 时 间 。 这 
是 因为 ， 当 数据 发 生变 动 时 ，MongoDB 不 仅 要 更 
新 文档 ， 还 要 更 新 集合 上 的 所 有 索引 。 因 此 ， 
MongoDB 限 制 每 个 集合 上 最 多 只 能 有 64 个 索引 。 
通常 ， 在 一 个 特定 的 集合 上 ， 不 应 该 拥有 两 个 以 
的 索引 。 于 是 ， 挑 选 合 适 的 字段 建立 索引 非常 
TE 


= 
里 女 。 


























































































































EN MongoDB 的 索引 几乎 与 传统 的 关系 





A 





开 ! 


会 介 
BI 








型 数据 库 索 引 一 
那些 技巧 ， 则 可 以 跳 过 本 节 的 语 
介绍 一 些 索引 的 基础 知识 


模 一 样 ， 所 




















里 涉及 的 
MySQL/Oracle/SQLite 索 引 的 技 ] 
MongoDB 包括 “Use the Index, Luke” 





4 是 冰山 一 角 。 


绝 大 多 数 优化 


以 如 果 已 经 掌握 了 
后 面 
要 记 住 这 























， 但 














中 同样 也 适用 于 
上 的 教 








程 http://use-the-index-luke.com) 。 
为 了 选择 合 


查询 ， 
Hs | 
































以 及 那些 需 
用 的 键 。 例 如 ， 在 上 
在 "username" 上 进行 
的 查询 ， 


或 者 ; 


适 的 键 来 建立 索引 ， 
对 要 被 优化 的 
而 的 




















这 个 查询 造成 





在 "username" 上 建立 索引 会 


然而 ， 如 果 这 只 




















日 AEH 


询 耗 费 的 时 间 





里 员 用 


有 的 查询 (管理 ! 











三 | 




















的 。 如 果 这 


可 以 查看 常用 的 
查询 ， 从 中 找 出 一 
HTF, EWE 
文 是 一 个 非常 通 
TERENS, ALA 
是 非常 好 的 选择 。 
































个 很 少 





KE 


到 的 查询 ， 或 者 只 
































内 











立 索 引 。 


5.1.1 


索引 的 值 是 按 一 
键 对 文档 进行 




















复合 索引 





索引 键 进行 排 














A SHER 




















) ， 那 就 不 应 该 


简介 


排序 非常 快 。 然 


! 并 不 需要 太 在 意 查 


定 顺序 排列 的 ， 




















对 "username" 建 





对 此 ， 使 用 索引 
只 有 在 首先 使 




















而 ， 








序 时 ， RIA 





"username" 


上 的 索引 没什么 

















有 用 。 





例如 ， 在 下 
E 
































> db.users.find().sort({"age" : 1, "userna 




















这 里 先 根据 "age" 排 序 再 根据 "username" 排 序 ， 
所 以 "username" 在 这 里 发 挥 的 作用 并 不 大 。 为 
了 优化 这 个 排序 ， 可 能 需要 

在 "age" 和 "username" 上 建立 索引 : 




































































> db.users.ensureIndex({"age" : 1, "userna 














这 样 就 建立 了 一 个 复合 索引 Ccompound 

index) 。 如 果 查 询 中 有 多 个 排序 方向 或 者 查询 条 
牛 中 有 多 个 键 ， 这 个 索引 就 会 非常 有 用 。 复 合 索 
引 就 是 一 个 建立 在 多 个 字段 上 的 索引 。 


假如 我 们 有 一 个 users 集 合 〈 如 下 所 示 ) ， 如 果 
在 这 个 集合 上 执行 一 个 不 排序 〈 称 为 自然 顺序 ) 
的 查询 : 




























































































> db.users. te frad 3 Oy i Oy. 
{ "username" "user@", "age" : 69 } 

{ "username" : "useri", "age" : 50 } 

{ "username" : "user2", "age" : 88 } 

{ "username" : "user3", "age" : 52 } 

{ "username" : "user4", "age" : 74 } 

{ "username" : "user5", "age" : 104 } 


















































{ "username" "user6", "age" : 59 } 
{ "username" "user7", "age" : 102 } 
{ "username" "user8", "age" : 94 } 
{ "username" "user9", "age" : 7 } 

{ "username" "user10", "age" : 80 } 
如 果 使 用 {"age”: 1, "username" : 1} 建 立 
索引 ， 这 个 索引 大 致 会 是 这 个 样子 : 

[@, "user10@309"] -> @x@c965148 

[@, "user10@334"] -> @xf51f818e 

[@, "user10@479"] -> @xeefd7934 

[@, "user99985" ] -> @xd246648Ff 

[1, "“user100156"] -> @xf78d5bdd 

[1, "“user100187"] -> @x68ab28bd 

[1, "user10@192"] -> @x5c7fb621 

[1, "user999920"] -> @x67ded4b7 

[2, "user10@141"] -> @x3996dd46 

[2, "user10@149"] -> @xfce68412 

[2, "user10@223"] -> @x91106e23 








一 个 索引 条 目 者 


个 "username" 字 段 ，3 














包含 一 个 "age "字段 和 一 























FEME OXY 














使 











入/ 








十 六 进 种 











并 且 指 向 文档 在 磁盘 上 的 
| 数字 J ARTIS » 可 以 忽 














KO 。 注 意 ， 这 里 的 "age" 字 段 是 严格 升序 排列 
的 ，"age" 相 同 的 条 目 按照 "username" 升 序 排 
列 。 每 个 "age" 都 有 大 约 8000 个 对 应 

的 "username"， 这 里 只 是 挑选 了 少量 数据 用 于 
传达 大 概 的 信息 。 


MongoDB 对 这 个 索引 的 使 用 方式 取决 于 查询 的 类 
型 。 下 面 是 三 种 主要 的 方式 。 




























































































e db.users.find({"age" : 
21}).sort({"username" : -1}) 
这 是 一 个 点 查询 (point query) ， 用 于 查找 
单个 值 ( 尽 管 包 含 这 个 值 的 文档 可 能 有 多 
个 ) 。 由 于 索引 中 的 第 二 个 字段 ， 查 询 结果 
已 经 是 有 序 的 了 : MongoDBE LLM {"age" : 
21} 匹 配 的 最 后 一 个 索引 开始 ， 逆 序 依 次 遍 
历 索引 : 




























































































[21, "user999977"] -> @x9b3160cf 
[21, "user999954"] -> @xfe@39231 
[21, "user9999@2"] -> @x719996aa 











这 种 类 型 的 查询 是 非常 高 效 的 :MongoDB 能 
够 直接 定位 到 正确 的 年 龄 ， 而 且 不 需要 对 结 





















































果 进 行 排序 (因为 只 需要 对 数据 进行 逆序 遍 
历 就 可 以 得 到 正确 的 顺序 了 》。 

注意 ， 排 序 方向 并 不 重要 : MongoDB 可 以 在 
竹 意 方向 上 对 索引 进行 遍历 。 


db.users.find({"age" : {"$gte" : 
21, "$lte" : 30}}) 

这 是 一 个 多 值 查询 (multi-value query) , Æ 
找到 多 个 值 相 匹配 的 文档 (在 本 例 中 ， 年 龄 
必须 介 于 21 到 30 之 间 ) 。MongoDB 会 使 用 索 
引 中 的 第 一 个 键 "age" 得 到 匹配 的 文档 ， 如 
下 所 示 : 

















































































































[21，"user166666"] -> @x37555a81 
[21, "user166669"] -> 6x6951d16f 
[21, "user1001"] -> 6Xx9a1lf5e6c 
[21, "user100253"] -> @xd54bd959 
[21, "user100409"] -> @x824fef6c 
[21, "user100469"] -> @x5fba778b 


[30, "user999775"] -> 6x45182d8c 
[30, "user999850"] -> 6x1df279e9 
[30, "user999936"] -> @x525caa57 















































通常 来 说 ， 如 果 MongoDB 使 用 索引 进行 查 
询 ， 那 么 查询 结果 文档 通常 是 按照 索引 顺序 
排列 的 。 












































e db.users.find({"age" : {"$gte" : 
21, "$lte™ : 
30}}).sort({"username":1}) 

这 是 一 个 多 值 查 询 ， 与 上 一 个 类 似 ， 只 是 这 
次 需要 对 查询 结果 进行 排序 。 跟 之 前 一 样 ， 
MongoDB 会 使 用 索引 来 匹配 查询 条 件 : 









































[21，"user166666"] -> @x37555a81 
[21, "user166669"] -> 6x6951d16f 
[21，"user1661"] ->  @x9a1f5e@c 
[21, "user100253"] -> @xd54bd959 


[22, "user166664"] -> @x81e862c5 
[22, "user100328"] -> @x83376384 
[22, "user166335"] -> @x55932943 
[22, "user100405"] -> @x20e7e664 





























然而 ， 使 用 这 个 索引 得 到 的 结果 集中 
"username" 是 无 序 的 ， 而 查询 要 求 结果 
以 "username" 升 序 排 列 ， 所 以 MongoDB 需 
要 先 在 内 存 中 对 结果 进行 排序 ， 然 后 才能 返 
本。 因此， 这 个 查询 通常 不 如 上 一 个 高 效 。 
当然 ， 查 询 速 度 取决 于 有 和 多少 个 文档 与 查询 
条 件 匹配 : 如 果 结 果 集 中 只 有 少数 几 个 文 
档 ，MongoDB 对 这 些 文档 进行 排序 并 不 需要 











































































































Pet 



































果 结 果 集中 的 文档 数 上 
会 比较 慢 ， 甚 至 根本 不 
的 大 小 超过 32 

比 多 的 数据 进 


MB， 
出 错 ， 拒 绝对 如 











耗费 多 少时 
较 多 ， 查 询 速 度 就 
FA: 如 果 结 果 旨 
MongoDB 就 会 


行 排序 : 


间 。 如 量 比 


\ 能 

























































































Mon Oct 29 16:25:26 uncaught exception 
"$err" "too much data for sort() 
specify a smaller limit", 
"code" : 10128 





} 


最 后 一 个 例子 中 ， 还 可 以 使 1 i 索引 (同样 
的 键 ， 但 是 顺序 调换 了 ) : {"username" : 1, 
"age" : 1}。MongoDB 会 反 转 所 有 的 索引 条 
目 ， 但 是 会 以 你 期 望 的 顺序 返回 。MongoDB 会 根 
据 索引 中 的 "age" 部 分 挑选 出 匹配 的 文档 : 

























































































["usere", 
["user1", 
["user1e", 
[ "user166"， 
["user1000", 
["user10000", 


69] 
50] 
80 

4 


["user100000", 
["user100001", 
["user100002", 
["user100003", 





] 
8] 
111] 
98] 

21] -> 0x73f0b48d 
60] 

82] 

27] -> 0x0078f55f 





["user166664"，22] -> 6x5f6d3688 
["user100005", 95] 






























































这 样 非常 好 ， 因 为 不 需要 在 内 存 中 对 大 量 数据 进 
行 排序 。 但 是 ，MongoDB 不 得 不 扫描 整个 索引 以 
便 找到 所 有 匹配 的 文档 。 因 此 ， 如 果 对 查询 结果 












































的 范围 做 了 限制 ， 那 么 MongoDB 在 几 次 匹配 之 后 
就 可 以 不 再 扫描 索引 ， 在 这 种 情况 下 ， 将 排序 键 
放 在 第 一 位 是 一 个 非常 好 的 策略 。 


可 以 通过 explain() 来 查看 MongoDB 对 
db.users.find({"age" : {"$gte" : 21, 
"$lte" : 30}}).sort({"username" : 1}) M4 
默认 行为 : 


> db.users.find({"age" : {"$gte" : 21, "$ 
. sort({"username" : 1}). 
. explain() 


































































































"cursor" : "BtreeCursor age 1 username 
"isMultikey" : false, 

"n" : 83484, 

"nscannedObjects" : 83484, 

"nscanned" : 83484, 
"nscannedObjectsAllPlans" : 83484, 
"nscannedAllPlans" : 83484, 








} 





"scanAndOrder" : true, 
"indexOnly" : false, 
"nYields" : 0, 
"nChunkSkips" : 0, 
"millis" : 2766, 


"“indexBounds" : { 
"age" 7 [ 
[ 
21, 
30 
] 
l 
"username" : [ 
[ 
{ 
"$minElement" 
} 
{ 
"$maxElement" 
} 
] 
] 
J 
"server" : "spock:27017" 


: 1 


: 1 





ze 
=| 
way 








可 以 忽略 大 部 分 字段 ， 后 面 会 有 相关 介 
Sau array See Sa 









































{"age" : 1, "user name" : 1: 而 且 只 查 
找 了 不 到 1/10 的 文档 ("nscanned" 只 有 
83484) ， 但 是 这 个 查询 耗费 了 差不多 3 和 的 时 间 
C"millis" 字 段 显示 的 是 毫秒 数 ) 。 这 里 
的 "scanAndorder" 字 段 的 值 是 true: 说 明 

MongoDB 必 须 在 内 存 中 对 数据 进行 排序 ， 如 之 前 
所 述 。 


可 以 通过 hint 来 强制 MongoDB 使 用 某 个 特定 的 索 
引 ， 再 次 执行 这 个 查询 ， 但 是 这 次 使 用 
"username" : 1, "age" : 1} 作 为 索引 。 这 
个 查询 扫描 的 文档 比较 多 ， 但 是 不 需要 在 内 存 中 
对 数据 排序 : 


> db.users.find({"age" : {"$gte" : 21, "$1 





























































































































. sort({"username" : 1}). 
.. hint({"username" : 1, "age" 1}) 
... explain() 
{ 
"cursor" : "BtreeCursor username_1_age 
"isMultikey" : false, 
"n" : 83484, 


"nscannedObjects" : 83484, 
"nscanned" : 984434, 
"nscannedObjectsAllPlans" : 83484, 
"nscannedAllPlans" : 984434, 
"scanAndOrder" : false, 








"indexOnly" : false, 
"nYields" : 0, 
"nChunkSkips" : @, 
"millis" : 14820, 
"“indexBounds" : { 
"username" : [ 
[ 
{ 
"$minElement" : 1 
J 
{ 
"$maxElement" : 1 
} 
] 
]， 
"age" : [ 
[ 
21, 
30 
] 
] 
J 


"server" 





"spock:27017" 











注意 ， 这 次 查询 耗费 了 将 近 
明 ， 第 一 个 索引 速度 更 快 。 然 而 ， 如 果 限 制 每 次 














15 秒 才 完 成 。 对 比 鲜 















































查询 的 结果 数量 ， 新 的 赢家 产生 了 : 








> db.users.find({"age" : {"$gte" : 21, "$1 


. sort({"username" : 1}). 

. limit(1000). 

. hint({"age" : 1, "username" : 1}). 

. explain()['millis'] 
2031 
> db.users.find({" age” : {"$gte" : 21, "$1 
... sort({"username" : 1}). 

. limit(100@). 

. hint({"username" : 1, "age" : 1}). 


... explain()['millis'] 
181 











第 一 个 查询 耗费 的 时 间 仍 然 介 于 2 秒 到 3 秒 之 间 ， 
但 是 第 二 个 查询 只 用 了 不 到 1/5 秒 ! 因此 ， 应 该 就 
在 应 用 程序 使 用 的 查询 上 执行 explain()。 排 除 
掉 那 些 可 能 会 导致 explain() 输 出 信息 不 准确 的 
选项 。 


在 实际 的 应 用 程序 中 ，{"sortkey"”: 1, 
"queryCriteria" : 1} 索 引 通 常 是 很 有 用 的 ， 
因为 大 多 数 应 用 程序 在 一 次 查询 中 只 需要 得 到 查 
询 结 果 最 前 面 的 少数 结果 ， 而 不 是 所 有 可 能 的 结 
果 。 而 且 ， 由 于 索引 在 内 部 的 组 织 形式 ， 这 种 广 
式 非常 易于 扩展 。 索 引 本 质 上 是 树 ， 最 小 的 值 在 
最 左边 的 叶子 上 ， 最 大 的 值 在 最 右边 的 叶子 上 。 
如 果 有 一 个 日 期 类 型 的 "sortKey" (或 是 其 他 能 



















































































































































































































































































够 随时 间 增 加 的 值 》》， 当 从 左 向 右 遍 历 这 棵 树 
时 ， 你 实际 上 也 花费 了 时 间 。 因 此 ， 如 果 应 用 程 
序 需 要 使 用 最 近 数 据 的 机 会 多 于 较 老 的 数据 ， 那 
么 MongoDB 只 需 在 内 存 中 保留 这 棵 树 最 右 侧 的 分 
文 〈 最 近 的 数据 ) ， 而 不 必 将 整 棵 树 留 在 内 存 
中 。 类 似 这 样 的 索引 是 右 平 衡 的 Cright 
balanced) ， 应 该 尽 可 能 让 索引 是 右 平 衡 

的 。"” id" 索 引 就 是 一 个 典型 的 右 平 衡 索引 。 

















































































































5.1.2 ”使 用 复合 索引 











在 多 个 键 上 建立 的 索引 就 是 复合 索引 ， 在 上 面 的 
小 节 中 ， 已 经 使 用 过 复合 索引 。 复 合 索引 比 单 键 
索引 要 复杂 一 些 ， 但 是 也 更 强大 。 本 节 会 更 深入 
也 介绍 复合 索引 。 


1. 选择 键 的 方向 


到 目前 为 止 ， 我 们 的 所 有 索引 都 是 升序 的 (或 者 
是 从 最 小 到 最 大 ) 。 但 是 ， 如 果 需 要 在 两 个 (或 
者 更 多 ) 查询 条 件 上 进行 排序 ， 可 能 需要 让 索引 
键 的 方向 不 同 。 例 如 ， 假设 我 们 要 根据 年 龄 从 小 
到 大 ， ] 户 名 从 Z 有 到 A 对 上 面 的 集合 进行 排序 。 对 
于 这 个 问题 ， 之 前 的 索引 变 得 不 再 高 效 : 每 一 个 
年 龄 分 组 内 都 是 按照 " username" 升 序 排列 的 ， 

















































































































是 A 到 Z， 不 是 Z 到 A。 对 于 
按 "username" de OA 用 上 




















掉 的 索引 得 到 的 数据 的 顺序 没什么 





F 按 "age" 升 序 排 列 

























































































为 了 在 不 同方 向 上 优化 这 个 复合 排序 ， 需 要 使 用 
与 方向 相 匹配 的 索引 。 在 这 个 例子 中 ， Bi 
{"age" : 1, "username" : -1}， 它 会 以 下 
面 的 方式 组 织 数 据 : 

[21, "user999977"] -> 6xe57bf737 

[21, "user999954"] -> 6x8bffa512 

[21, "user999902"] -> @x9e1447d1 

[21, "user999900"] -> 6x3a6a8426 

[21, "user999874"] -> 6xc353ee66 

[30, "user999936"] -> 6x7f39a81a 

[30, "user999850"] -> @xa979e136 

[30, "user999775"] -> @x5de6b77a 

[30, "user100324"] -> 6xe14f8e4d 

[30, "user100140"] -> @xef34d446 

[30, "user166656"] -> @x223c35b1 








HY 











FE 龄 按照 从 年 轻 到 年 长 顺序 排列 ， 
分 组 中 ， 月 


在 每 一 个 年 龄 
有 户 名 是 从 Z 到 A 排列 的 《对 于 我 们 的 月 
记名 来 说 ， 也 可 以 说 是 按照 "9" 到 "8" 排 列 的 ) 。 



































如 果 应 用 程序 同时 需要 按照 {"age"”: E 


"username" : 1} 优 化 排序 ， 我 们 还 需要 创建 一 


个 这 个 方向 上 的 索引 。 至 于 索引 使 的 方向 ， 与 















































排序 方向 相同 就 可 以 了 。 注 意 ， 
个 方向 都 乘 以 -1) 的 索引 是 等 价 的 : {"age' 


1, 


: -1, 














"user name" : -1} 适 用 


完全 一 样 的 。 


"username" : 1} 是 


相互 反 转 〈 在 每 





ae wee 


















































只 有 基于 多 个 查询 条 件 进 行 排序 时 ， 索 引 方 向 才 








是 比较 重要 的 。 如 果 只 是 基于 单一 键 进行 排序 ， 
MongoDB 可 以 简 单 地 从 相反 方向 读 取 索引 。 例 


如 ， 如 果 有 一 个 基于 {” age" 
个 基于 {"age"” : 1} 的 索引 ， MongoDB 会 在 使 用 
索引 时 进行 优化 ， 就 如 同 存在 一 
































: -1} 的 排序 和 一 





个 {"age" 


-1} 索 引 一 样 (所 以 不 要 创建 两 个 这 样 的 索 


LY 





HE, 
Zo 


2. 使 























只 有 在 基于 多 键 排序 时 ， 方 向 才 变 得 重 





FA HAS) (covered index) 








在 上 












































要 获取 实际 的 文档 。 当 一 














请 求 和 
查询 。 





看 的 例子 中 ， 查 询 只 是 用 来 查找 正确 的 文 

档 ， 然 后 按照 指示 获取 实际 的 文档 。 然 后 ， 如 果 
你 的 查询 只 需要 查找 索引 中 包含 的 字段 ， 那 就 根 
ASSL 



































个 索引 包含 用 户 


的 所 有 字段 ， 可 以 认为 这 个 索引 覆盖 了 本 次 

















在 实际 中 ， 应 该 优先 使 月 


日 履 盖 索引 ， 而 不 



























































使 用 




















可 能 还 需要 对 不 需 














是 去 获取 实际 的 文档 。 这 样 可 以 保证 工作 集 比 较 
小 ， 尤 其 与 右 平衡 索引 一 起 使 用 时 。 

为 了 确保 查询 只 使 用 索引 就 可 以 完成 ， 应 该 
投射 ( 详 见 4.1.1 节 ) 来 指定 不 要 返回 "_ id" 字段 
(除非 它 是 索引 的 一 部 分 ) 。 

要 查询 的 字段 做 索引 ， 因 此 需要 在 编写 时 就 在 
































所 





需 的 查询 速度 和 这 种 方式 带 来 的 开销 之 间 做 好 权 























OR FEE mR IEA 
4Fexplain(), 


为 true。 

















如 果 在 一 个 








中 的 ，5.1.4 节 








节 会 深入 介 





"indexonly" 字 段 的 值 要 























含有 数组 的 字段 上 做 索引 ， 这 个 索引 
永远 也 无 法 覆盖 查询 《因为 数组 是 被 保存 在 索引 
绍 ) 。 即 便 将 数组 字段 从 





需要 返回 的 字段 中 剔除 ， 这 样 的 索引 仍然 无 法 履 


aH. 





3. 隐 式 索引 

















复合 索引 
表现 为 不 同 


"username" 











的 索引 。 


: ayes, | 
序 ， 就 好 像 有 一 个 {"age" 























如 果 有 一 个 {"age' 


具有 双重 功能 ， We 


ra he enn 
: 1} 索 引 一 样 。 因 


和 
使 用 } 


这 个 可 以 根据 需要 推广 到 尽 可 能 多 的 键 : 如 果 有 
一 个 拥有 N 个 键 的 索引 ， 那 么 你 同时 “免费 ”得 到 
P tet de 举例 来 说 ， 
如 果 有 一 个 {"a": 1, "b": 1, "c": 1, 
cera. C2 1} 索 引 ， 那么 ， 实 际 上 我 们 也 可 以 
使 用 {"a": 1}、{"a": 1, "b" : 1}、 {"a": 
1, "b": 1, "c": 1} 等 一 系列 索引 。 


注意 ， 这 些 键 的 任意 子 集 所 组 成 的 索引 并 不 一 定 
可 用 。 例 如 ， 使 用 {"b": 1} 或 者 {"a": 1, 
"c": 1} 作 为 索引 的 查询 是 不 会 被 优化 的 ， 只 有 
能 够 使 用 索引 前 级 的 查询 才能 从 中 受益 。 
























































































































































5.1.3 $ 操 作 符 如 何 使 用 索引 














有 一 些 查 询 完全 无 法 使 用 索引 ， 也 有 一 些 查 询 能 
够 比 其 他 查询 更 高 效 地 使 用 索引 。 本 节 讲 述 
MongoDB 对 各 种 不 同 查询 操作 符 的 处 理 。 
1. 低 效率 的 操作 符 


有 一 些 查 询 完全 无 法 使 用 索引 ， 比 






















































































如 "$where" 查询 和 检查 一 个 键 是 否 存在 的 查询 
({"key" : {"$exists" : true}}) 。 也 有 
其 他 一 些 操作 不 能 高 效 地 使 用 索引 。 


如 果 "x" 上 有 一 个 索引 ， 查 询 那些 不 包含 "x" 键 的 
文档 可 以 使 用 这 样 的 索引 ({"x"” : {"$exists" 
: false}}。 然 而 ， 在 索引 中 ， 不 存在 的 字段 和 
nu1l1 字 段 的 存储 方式 是 一 样 的 ， 查 询 必须 遍历 每 
一 个 文档 检查 这 个 值 是 否 真 的 为 nul1 还 是 根本 不 
存在 。 如 果 使 用 稀疏 索引 (sparse index) ， 就 不 
能 使 用 {"$exists”: true}， 也 不 能 使 
j{"$exists”: false}. 


通常 来 说 ， 取 反 的 效率 是 比较 低 的 。"$ne" 查 询 
可 以 使 用 索引 ， 但 并 不 是 很 有 效 。 因 为 必须 要 查 
看 所 有 的 索引 条 目 ， 而 不 只 是 "$ne" 指 定 的 条 

目 ， 不 得 不 扫描 整个 索引 。 例 如 ， 这 样 的 查询 裔 
历 的 索引 范围 如 下 : 



































































































































































































































































































































> db.example.find({"i" : {"$ne" : 3}}).exp 
{ 


"cursor" : "BtreeCursor i_1 multi", 
sees 
"“indexBounds" : { 
as Ea : [ 
[ 











"¢minElement" 


"¢maxElement" 





这 个 查询 查找 了 所 有 人 小 了 
索引 中 值 为 3 的 条 日 
民 不 错 的 ， 
































3 和 大 于 
非常 多 ， 
































3 的 索引 条 目 。 
那么 这 个 查询 
one 这 个 查询 就 不 得 











不 检查 几乎 所 有 的 索引 条 




















"$not" 有 时 能 够 使 用 索引 ， 
要 如 何 使 用 索引 。 
































且 是 通常 它 并 不 知道 











韦 











将 {"key”: 
{"$gte" 


蕊 能够 对 基本 的 范围 《〈 比 如 
{"$1t" : 7}} Æ {"key" 








: 7}}) 和 正则 表达 式 进行 反 转 。 然 














而 ， 大 多 数 使 
表 扫 描 。 








"$nin" 就 总 








中 























j"$not" 的 查询 都 会 退化 为 进行 4 


是 进行 全 表 扫 描 。 











JE 





























如 果 需 要 快速 执行 一 个 这 些 类 型 的 查询 ， 可 以 试 
着 找到 另 一 个 能 够 使 用 索引 的 语句 ， 将 其 添加 到 
查询 中 ， 这 样 就 可 以 在 MongoDB 进 行 无 索引 匹配 
(non-indexed matching) 时 先 将 结果 集 的 文档 数 
量 减 到 一 个 比较 小 的 水 平 。 
假如 我 们 要 找 出 所 有 没有 "birthday" 字 段 的 用 
户 。 如 果 我 们 知道 从 3 月 20 开 始 ， 程 序 会 为 每 一 
个 新 用 户 添 加 生日 字段 ， 那 么 就 可 以 只 查询 3 月 
20 之 前 创建 的 用 户 : 


> db.users.find({"birthday" : {"$exists" 

































































































































































这 个 查询 中 的 字段 顺序 无 关 紧 要 ，MongoDB 会 自 
动 找 出 可 以 使 用 索引 的 字段 ， 而 无 视 查 询 中 的 字 
段 顺序 。 


















































2. 范围 


复合 索引 使 MongoDB 能 够 高 效 地 执行 拥有 多 个 语 
句 的 查询 。 设 计 基 于 多 个 字段 的 索引 时 ， 应 该 将 
会 用 于 精确 匹配 的 字段 《比如 "x"”: "foo") 放 
在 索引 的 前 看 ， 将 用 于 范围 匹配 的 字段 〈 比 

如 "y”: {"$gt" : 3, "$lt" : 5}) 放 在 最 
后 。 这 样 ， 查询 就 可 以 先 使 用 第 一 个 索引 键 进行 
精确 匹配 ， 然 后 再 使 用 第 二 个 索引 范围 在 这 个 结 

































































































































































果 集 内 部 进行 搜索 。 假 设 要 使 用 {"age"” : 1, 
"username" : 1} 索 引 查询 特定 年 龄 和 用 户 名 范 
羽 内 的 文 要 ， 可 以 精确 指定 索引 边界 值 : 






































> db.users.find({"age" : 47, 
... "username" : {"$gt" : "user5", "$1t" : 
{ 
"cursor" : "BtreeCursor age_1_username 
"n" : 2788, 
"nscanned" : 2788, 
batts 
“indexBounds" : { 
"age" : [ 
[ 
47, 
47 
] 
]， 
"username" : [ 
[ 
"user5", 
"user8" 
] 
] 
J 








这 个 查询 会 直接 定位 到 "age" 为 47 的 索引 条 目 ， 
然后 在 其 中 搜索 用 户 名 介 
于 "users" 和 "user8" 的 条 5 












































有 反 过 来 ， 假 如 使 用 {"username" : 1, "age" 
: 1} 索 引 ， 这 样 就 改变 了 查询 计划 (query 
plan) ， 碍 询 必 须 先 找到 介 

于 "user5" 和 "user8" 之 间 的 所 有 月 
从 中 挑选 "age" 等 于 47 的 用 户 。 



































户 ， 然 后 再 


aa 














> db.users.find({"age" : 47, 
"username" : {"$gt" : "user5", "$1t" 
{ 


"cursor" : "BtreeCursor username_1_age 
"n" : 2788, 
"nscanned" : 319499, 


betes 
"indexBounds" : { 
"username" : [ 


[ 


"user5", 
"users" 


age" : [ 


47, 
47 








] 
}, 
"server" : "spock:27017" 
} 











本 次 查询 中 MongoDB 扫 描 的 索引 条 目 数量 是 前 一 
个 查询 的 10 倍 ! 在 一 次 查询 中 使 用 两 个 范围 通常 
会 导致 低 效 的 查询 计划 。 

































































3. OR 查询 

















写作 本 书 时 ，MongoDB 在 一 次 查询 中 只 能 使 用 一 
个 索引 。 如 果 你 在 {"x”: 1} 上 有 一 个 索引 ， 
在 {"y”: 1} 上 也 有 一 个 索引 ， 在 {"x" 

123, "y" : 456} 上 进行 查询 时 ，MongoDB 会 
使 用 其 中 的 一 个 索引 ， 而 不 是 两 个 一 起 
 。"$or" 是 个 例外 ，"$or" 可 以 对 每 个 子 句 都 
使 用 索引 ， 因 为 "$or" 实 际 上 是 执行 两 次 查询 然 
后 将 结果 集合 并 。 



















































































> db.foo.find({"$or" : [{"x" : 123}, {"y" 
{ 


"clauses" : [ 


{ 


"cursor" : "BtreeCursor x_1", 
"isMultikey" : false, 





o aa A 
"nscannedObjects" : 1, 
"nscanned" : 1, 
"nscannedObjectsAllPlans" 
"nscannedAllPlans" : 1, 
"scanAndOrder" : false, 
"indexOnly" : false, 
"nYields" : 0, 
"nChunkSkips" : 6， 
"millis" : 6， 
"indexBounds" : { 

"x": [ 


"cursor" : "BtreeCursor y_1", 
"isMultiKey" : false, 

Ph aT 

"nscannedObjects" : 1, 
"nscanned" : 1, 
"nscannedObjectsAllPlans" : 1, 
"nscannedAllPlans" : 1, 
"scanAndOrder" : false, 
"indexOnly" : false, 





"nYields" : 6， 
"nChunkSkips" : 6， 


"millis" : @, 
"“indexBounds" : { 
"y": [ 
[ 
456, 
456 
] 
] 
} 
} 
]， 
”3 
"nscannedObjects" : 2, 
"nscanned" : 2, 
"nscannedObjectsAl1Plans" 
"nscannedAllPlans" : 2, 
"millis" : 0, 
"server" : "spock:27017" 





} 


S25 








可 以 看 到 ， 这 次 的 explain() 输 出 结果 由 
立 的 查询 组 成 。 通 常 来 说 ， 执 行 两 次 查询 再 ; 















































历次 独 














oe 

















b, MiZ 








果 合 并 的 效率 不 如 单 次 查询 高 ， 基 
能 使 用 "$in" 而 不 是 "$or"。 





















































RE] 


如 果 不 得 不 使 用 "$or"， 记 住 ，MongoDB 需 要 检 




















查 每 次 查询 的 结果 集 并 且 从 中 移 除 重复 的 文档 
《有 些 文档 可 能 会 被 多 个 "$or" 子 句 匹 配 到 ) 


使 用 "$in" 碍 询 时 无 法 控制 返回 文档 的 顺序 〈 除 
非 进行 排序 ) "例如 ， 使 用 {"x"” : [1， 2, 

3]} 与 使 用 {"x”: [3， 2， 1]} 得 到 的 文档 顺 
序 是 相同 的 。 




























































































5.1.4 索引 对 象 和 数组 


MongoDB 人 允许 深入 文档 内 部 ， 对 藤 套 字段 和 数组 
建立 索引 。 藤 套 对 象 和 数组 字段 可 以 与 复合 索引 
中 的 顶级 字段 一 起 使 用 ， 虽 然 它 们 比较 特殊 ， 但 
与 “正常 "索引 字段 的 行为 是 一 臻 















































1. AGES 


可 以 在 散 套 文档 的 键 上 建立 索引 ， 方 式 与 正常 的 
键 一 样 。 如 果 有 这 样 一 个 集合 ， 其 中 的 第 一 个 文 
档 表 示 一 个 用 户 ， 可 能 需要 使 用 舱 套 文档 来 表示 
每 个 用 户 的 位 置 : 

















































































































{ 


"username" : "sid", 
"loc" : { 


"ip" : "1.2.3.4", 
"city" : "Springfield", 
"state" : "NY" 





要 在 "loc "的 某 一 个 子 字段 〈 比 
如 "loc.city") 上 建立 索引 ， 以 便 提 高 这 个 字 
段 的 查询 速度 : 














> db.users.ensureIndex({"loc.city" : 1}) 
































可 以 用 这 种 方式 对 任意 深层 次 的 字段 建立 索引 ， 
比如 你 可 以 在 "x.y.z.w.a.b.c" 上 建立 索引 。 

















ER, WREEF Cloc") 建立 索引 ， 与 
对 谍 套 文档 的 某 个 字段 〈"loc.city") 建立 索 
引 是 不 同 的 。 对 整个 子 文档 建立 索引 ， 只 会 提高 
整个 子 文档 的 查询 速度 。 在 上 面 的 例子 中 ， 只 有 
在 进行 与 子 文档 字段 顺 ) 子 完全 匹配 的 了 文档 查询 
时 《比如 db.users.find({"loc" : {"ip" 
"123.456.789.000", "city" : 
"Shelbyville", "state" : "NY"}}})) , 
查询 优化 器 才 会 使 用 "loc" 上 的 索引 。 无 法 对 
如 db.users.find({"loc.city" 
"Shelbyville"}) 的 查询 使 用 索引 。 
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2. 索引 数组 


也 可 以 对 数组 建立 索引 ， 这 样 就 可 以 高 效 地 搜索 
数组 中 的 特定 元 素 。 


段 如 有 一 个 博客 文章 的 集合 ， 其 中 每 个 文档 表示 
篇 文章 。 每 篇 文章 都 有 一 个 "comments" 字 
段 ， 这 是 一 个 数组 ， 其 中 每 个 元 素 都 是 一 个 评论 
子 文档 。 如 果 想 要 找 出 最 近 被 评论 次 数 最 多 的 博 
客 文章 ， 可 以 在 博客 文章 集合 中 骸 套 

的 "comments" 数 组 的 "date" 键 上 建立 索引 : 


























































































































> db.blog.ensureIndex({"comments.date" : 1| 





对 数组 建立 索引 ， 实 际 上 是 对 数组 的 每 一 个 元 素 
建立 一 个 索引 条 目 ， 所 以 如 果 一 篇 文章 有 20 条 评 
论 ， 那 么 它 就 拥有 20 个 索引 条 目 。 因 此 数组 索引 
的 代价 比 单 值 索引 高 : 对 于 单 次 插入 、 更 新 或 者 
州 除 ， 每 一 个 数组 条 目 可 能 都 需要 更 新 (可 能 

上 千 个 索引 条 目 〉。 


与 上 一 节 中 "1oc "的 例子 不 同 ， 无 法 将 整个 数组 
作为 一 个 实体 建立 索引 : 对 数组 建立 索引 ， 实 际 
上 是 对 数组 中 的 每 个 元 素 建立 索引 ， 而 不 是 对 数 
组 本 身 建 并 索引 。 














































































































在 数组 上 建立 的 索引 并 不 包含 任何 位 置信 息 : 无 
en T 的 数组 元 素 ， 比 


如 "comments .4" 


少数 特殊 情况 下 ， 可 以 对 某 个 特定 的 数组 条 目 进 
行 索引 ， 比 如 : 







































































> db.blog.ensureIndex({"comments.10.votes" 

















然而 ， 只 有 在 精确 匹配 第 11 个 数组 元 素 时 这 个 索 
引 才 有 用 《数组 下 标 从 0 开始 ) 。 


一 个 索引 中 的 数组 字段 最 多 只 能 有 一 个 。 这 是 为 
了 避免 在 多 键 索 引 中 索引 条 目 爆 炸 性 增长 : 每 一 
对 可 能 的 元 素 都 要 被 索引 ， 这 档 导致 每 个 文档 j 
有 n*m 个 索引 条 目 。 假 如 有 一 个 {"x"” : 1，"y" 
: 1}+ 上 的 索引 : 




















































































































// x 是 一 个 数组 一 这 是 合 法 的 
db.multi.insert({"x" : [1, 2, 3], "y" 





> 

> 

> 

> // y 是 一 个 数组 一 这 也 是 合法 的 

> db.multi.insert({"x" : 1, "y" : [4, 5, 6 
> 

> 

> 

C 





// x 和 y 都 是 数组 一 这 是 非法 的 ! 
db.multi.insert({"x" : [1, 2, 3], "y" 
annot index parallel arrays [y] [x] 
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MongoDB 要 为 上 再 
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1, 
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i 的 最 后 一 个 例 TUER 


: {"x" : 

: Sh. {"x" 
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aa 和 
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3. 多 键 索 引 


对 于 某 个 索引 的 键 ， 如 果 
一 个 数组 ， 那 么 这 个 索引 就 会 被 标记 为 多 键 索引 
(multikey index) 。 可 以 从 explain() 的 输出 : 
看 到 一 个 索引 是 否 为 多 键 索 引 : 如 果 使 用 了 多 键 
索引 ，"isMultikey" 字 段 的 值 会 是 true。 索 引 
只 要 被 标记 为 多 键 索引 ， 就 无 法 再 变 成 非 多 键 索 
引 了 ， 即 使 这 个 字段 为 数组 的 所 有 文档 都 从 集合 
Ro BLY BER S| PRINS ERI, ME 
法 就 是 删除 再 重建 这 个 索引 。 


well 

多 键 索引 可 能 会 比 非 多 键 索引 慢 一 些 。 可 能 会 有 

多 个 索引 条 目 指向 同一 个 文档 ， 因 此 MongoDB 在 
的 内 容 。 


ig (AY ply teas ae e 














这 个 键 在 某 个 文档 中 是 




































































































































































5.1.5 索引 基数 


























基数 (cardinality) 就 是 集合 中 某 个 字段 拥有 不 同 
值 的 数量 。 有 一 些 字段 ， 比 如 "gender "或 

者 "newsletter opt-out"， 可 能 只 拥有 两 个 可 
能 的 值 ， 这 种 键 的 基数 就 是 非常 低 的 。 另 外 一 些 
字段 ， 比 如 "username" 或 者 "email"， 可 能 集合 
中 的 每 个 文档 都 拥有 一 个 不 同 的 值 ， 这 类 键 的 基 
数 是 非常 高 的 。 当 然 也 有 一 些 介 a 
段 ， 比 如 "age" 或 者 "zip code" 


通常 ， 一 个 字段 的 基数 越 高 ， 这 个 键 上 的 索引 就 
越 有 用 。 这 是 因为 索引 能 够 迅速 将 搜索 范围 缩小 
到 一 个 比较 小 的 结果 集 。 对 于 低 基数 的 字段 ， 索 
引 通常 无 法 排除 掉 大 量 可 能 的 匹配 。 


假设 我 们 在 "gender" 上 有 一 个 索引 ， 需 要 查找 
名 为 Susan 的 女性 用 户 。 通 过 这 个 索引 ， 只 能 将 搜 
索 空间 缩小 到 大 约 50%， 然 后 要 在 每 个 单独 的 文 
档 中 查找 "name" 为 "Susan" 的 用 户 。 反 过 来 ， 如 
果 在 "name" 上 建立 索引 ， 就 能 立即 将 结果 集 缩 小 
到 名 为 "Susan" 的 用 户 ， 这 样 的 结果 集 非常 小 ， 
然后 就 可 以 根据 性 别 从 中 迅速 地 找到 匹配 的 文档 
Ta 


一 般 说 来 ， 应 该 在 基数 比较 高 的 键 上 建立 索引 ， 
























































































































































































































































































































































或 者 至 少 应 该 












































5.2 ”使 用 explain0 和 hintO 





从 上 








说 ， 这 是 最 重要 
查询 的 explain( 
了 哪个 索引 ， 
询 ， 



































的 诊断 
) 输 
以 及 是 如 何 使 
都 可 以 在 最 后 添加 一 个 explain()i 





对 于 j 


严 基数 较 高 的 键 放 在 复合 索引 的 前 
A CARER BE HT) 。 














而 的 内 容 可 以 看 出 ，explain() 能 够 提供 
量 与 查询 相关 的 信息 。 
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IEA EK 








工具 之 














出 信息 ， 可 以 和 道 查 



































的 。 对 于 人 
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《与 


调用 sort() 或 者 limit() 一 样 ， 不 过 explain() 





必须 放 在 最 后 ) o 


Fal | 


BY 








的 查询 和 没有 使 用 索引 日 





索引 ， 
大 部 分 字段 都 是 术 
个 explain() 的 聚 




















不 使 用 





索引 的 查询 上 








explain() 类 型 。 如 

















对 为 它 使 用 了 "Basi 








生成 的 查询 计划 可 能 
AU. Ah, 
EG (第 13 
询 会 在 多 个 服务 器 上 

















能 会 
章 会 介 


执行 。 


些许 不 
分 片 返 





见 的 explain() 输 出 有 两 种 类 型 : 使 用 索引 
的 查询 。 对 于 特殊 类 型 


:的 





司 ， 但 是 


口 

















exlpain() 是 最 基 


果 一 个 查询 不 


cCursor"( 基 




















过 来 说 ， 大 部 分 使 | 





索引 的 查询 使 


本 的 
使 用 索引 ， 
本 游标 ) 。 
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的 是 多 
24) ， 因 为 查 





5 


是 BtreeCursor 〈 某 些 特殊 类 型 的 索引 ， 比 如 地 




















理 空 间 索 引 ， 使 用 的 是 它们 自己 类 型 的 游标 ) 。 


对 于 使 用 了 复合 索引 的 查询 ， 最 简单 情况 下 的 
explain() 输 出 如 下 所 示 ; 
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> db.users.find({"age" : 42}).explain() 
{ 
"cursor" : "BtreeCursor age_1_username 
"isMultiKey" : false, 
"n" : 8332, 
"nscannedObjects" : 8332, 
"nscanned" : 8332, 
"nscannedObjectsAllPlans" : 8332, 
"nscannedAllPlans" : 8332, 
"scanAndOrder" : false, 
"indexOnly" : false, 
"nYields" : 0, 
"nChunkSkips" : 0, 
"millis" : 91, 
"indexBounds" : { 
"age" : [ 
[ 
42, 
42 


] 
], 


"username" : [ 


[ 
{ 








"¢minElement" : 1 
js 
"¢maxElement" : 1 
} 
] 
] 
js 
"server" : "“ubuntu:27017" 
} 





























从 输出 信息 中 可 以 看 到 它 使 用 的 索引 

是 age_1_username_1。"millis" 表 明了 这 个 查 
询 的 执行 速度 ， 时 间 是 从 服务 器 收 到 请 求 开始 
直到 发 出 响应 为 止 。 然 而 ， 这 个 数值 不 一 定 真 的 
是 你 希望 看 到 的 值 。 如 果 MongoDB 党 试 了 多 个 查 
询 计划 ， 那 么 "millis" 显 示 的 是 这 些 查 询 计划 
花费 的 总 时 间 ， 而 不 是 最 优 查 询 计划 所 花 的 时 
on 


接 下 来 是 实际 返回 的 文档 数量 : "n"。 它 无 法 反 
映 出 MongoDB 在 执行 这 个 查询 的 过 程 中 所 做 的 工 
Ye: 搜索 了 多 少 索引 条 目 和 文档 。 索 引 条 目 是 使 
j "nscanned" 描 述 的 。"nscanned0bjects" 字 
段 的 值 就 是 所 扫描 的 文档 数量 。 最 后 ， 如 果 要 对 
结果 集 进行 排序 ， 而 MongoDB 无 法 对 排序 使 用 索 
引 ， 那 么 "scanAndorder" 的 值 就 会 是 true。 也 
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就 是 说 ，MongoDB 不 得 不 在 内 存 中 对 结果 进行 排 

























































































































































































序 ， 这 是 非常 慢 的 ， 而 且 结 果 集 的 数量 要 比较 
小 。 

现在 你 已 经 知道 这 些 基础 知识 了 ， 接 下 来 依次 详 
细 介 绍 这 些 字 段 。 

e "cursor" : "BtreeCursor 
age_1_username_1" 
BtreeCursor 表 示 本 次 查询 使 用 了 索引 ， 具 
体 来 说 ， 是 使 用 了 "age" 和 "username" 上 的 
索引 {"age”: 1, "username" : 1}。 如 
果 查 询 要 对 结果 进行 逆序 遍历 ， 或 者 是 使 用 
了 多 键 索 引 ， 就 可 以 在 这 个 字段 中 看 
到 "reverse" 和 "multi" 这 样 的 值 。 

e "isMultiKey" : false 
用 于 说 明 本 次 查询 是 否 使 用 了 多 键 索 引 【〈 详 
见 $.1.4 节 ) 。 

e "n" : 8332 
本 次 查询 返回 的 文档 数量 。 

e "nscannedObjects" : 8332 





这 是 MongoDB 按 照 索引 指针 去 磁盘 上 和 查找 实 

















际 文档 的 次 数 。 如 果 查 询 包含 














9 查询 条 件 不 








是 索引 的 一 部 分 ， 或 者 说 要 求 返 回 不 在 索引 














内 的 字段 ，MongoDB 就 必须 依次 查找 每 个 索 


引 条 目 指向 的 文档 。 


"nscanned" : 8332 






























































iD 


里。 





"scanAndorder" : false 























如 果 有 使 用 索引 ， 那 么 这 个 数字 就 是 查找 过 
的 索引 条 目 数 量 。 如 果 本 次 查询 是 一 次 全 表 
习 描 ， 那 么 这 个 数字 就 表示 检查 过 的 文档 数 








MongoDB 是 否 在 内 存 中 对 结果 集 进 行 了 排 








序 。 


"indexOnly" : false 








MongoDB 是 否 只 使 用 索引 就 能 完成 此 次 查询 





〈 详 见 “ 覆 盖 索 引 ?部 分 ) 。 














在 本 例 中 ，MongoDB 只 使 用 索引 就 找到 了 全 
部 的 匹配 文档 ， 从 "nscanned" 和 "n" 相 等 就 

















可 以 看 出 来 。 然 而 ， 本 次 查询 要 求 返 
文档 中 的 所 有 字段 ， 而 索引 只 包 








a] VO ao 


























含 "age" 和 "username" 两 个 字段 。 如 果 将 本 





次 查询 修改 为 ({"_id" : 0, "age" 





1, "username" : 1}) ， 那 么 本 次 查询 就 
可 以 被 索引 覆盖 了 ，"indexonly" 的 值 就 会 





是 true。 








"nYields" : © 











为 了 让 写 入 请 求 能 够 顺利 执行 ， 本 次 查询 暂 























停 的 次 数 。 如 果 有 写 入 请 
地 释放 它们 的 锁 ， 





会 周期 性 











青 求 需 要 处 TI 查询 



































以 便 写 入 能 够 顺 


利 执行 。 然 而 ， 在 本 次 查询 中 ， 没 有 写 入 请 








求 ， 因 为 查询 没有 和 暂停 过 。 


"millis" : 91 








数据 库 执 行 本 次 查询 
说 明 查 询 


数字 越 小 ， 


"indexBounds" 























引 的 遍历 范围 。 









































对 此 这 个 索引 键 








所 耗费 
效率 越 高 


> {i 
这 个 字段 描述 了 索引 的 使 月 











的 毫秒 数 。 这 个 


= 
[本 o 





情况， 给 出 了 索 
由 于 查询 中 的 第 一 个 语句 是 
精确 匹配 ， 因 此 索引 只 需要 查找 42 这 个 值 就 
可 以 了 。 本 次 查询 没有 
EBA BRR ii 











间 定 第 二 个 索引 键 ， 


1， 数 据 库 会 











在 "age" 为 和 2 的 条 
("$minElement" 
("$maxElement" 








i 











: 1, 
sr d; 

















; 将 | 








: 1) 


"age" 


"username" 


























用 户 名 介 于 负 无 穷 
: 1) 和 正 无 穷 











的 条 目 都 找 出 来 。 





了 来 看 一 个 稍微 复杂 点 的 例子 : 假如 有 一 个 
{"user name" 
一 个 {"age" 
引 。 同 时 查询 "username" 和 "age" 时 ， 会 发 生 什 
么 情况 ? We, mR 





: 1} 上 的 索引 和 
: 1} 上 的 索 





\ 体 的 查询 : 





> db.c.find({age : {$gt : 10}, username : 


"cursor" : "BtreeCursor username_1_age 
"indexBounds" : [ 
[ 
{ 
"username" : "sally", 
"age" : 10 
js 
{ 
"username" : "sally", 
"age" : 1.7976931348623157 
} 
] 
]， 
"nscanned" : 13, 
"nscannedObjects" : 13, 
"n" : 13, 
"millis" : 5 








} 


由 于 在 要 在 "username" 上 执行 精确 匹配 ， 
在 "age" 上 进行 范围 查询 ， 因 此 ， 数 据 库 选 择 使 
J{"username" : 1, "age" : 1} 索 引 ， 这 与 
查询 语句 的 顺序 相反 。 男 一 方面 来 说 ， 如 果 需 要 
对 "age "精确 匹配 而 对 "username "进行 范围 查 
询 ，MongoDB 就 会 使 用 另 一 个 索引 ， 























































































































> db.c.find({"age" : 14, "username" : /.*/ 


{ 


"cursor" : "BtreeCursor age 1 username 
"indexBounds" : [ 
[ 
{ 
"age" : 14, 
"username" ad 
J 
{ 
"age" : 14, 
"username" : { 
} 
} 
]， 
[ 
{ 
"age" : 14, 
"username" : /.*/ 
J 
{ 
"age" : 14, 
"username" : /.*/ 
} 
] 
]， 
"nscanned" : 2, 
"nscannedObjects" : 2, 


"n": 2， 





"millis" : 2 
} 
































如 
的 








ZWE 






































发 现 MongoDB 使 用 的 索引 与 
引 不 一 致 ， 可 以 使 用 hit() 强 制 MongoDB 使 











9 己 希 望 它 使 用 












































特定 的 索引 。 例 如 ， 如 果 希 望 MongoDB 在 上 个 





列子 的 查询 中 使 用 {"username" : 1, "age" 
> 1} 索 引 ， 可 以 这 么 做 : 
> db.c.find({"age" : 14, "username" : /.*/ 























如 果 查 询 没有 使 用 你 希望 它 使 月 
使 用 hint 强 制 MongoDB 使 用 某 个 索引 ， 那 么 应 该 














的 索引 ， 于 是 你 



























































查询 优化 器 








MongoDB 的 查询 优化 器 与 














其 他 数 
基本 来 说 ， 如 采 一 个 索引 能 够 精确 匹配 一 个 查询 





在 应 用 程序 部 署 之 前 在 所 指定 的 索引 上 执 

行 explain()。 如 果 强 制 MongoDB 在 某 个 查询 上 
使 用 索引 ， 而 这 个 查询 不 知道 如 何 使 用 这 个 索 
引 ， 这 样 会 导致 查询 效率 降低 ， 

















还 不 如 不 使 用 索 


KEHADE. 








《要 查询 "x"， 刚 好 在 "x" 上 有 一 个 索引 ) » WA 





























查询 优化 器 就 会 使 j 这 个 索引 。 





不 然 的 话 ， 可 能 


全 有 几 个 未 引 革 适合 你 的 查询 ”MonbaDB 信 从 这 








些 可 和 
这 些 查 


这 个 


的 索引 子 集中 为 每 次 查询 
十 划 是 并 行 执行 的 。 
果 的 就 是 胜 者 ， 其 人 


十 划 会 被 缓存 ， 


查询 1 


查询 i 








计划 选择 一 个 ， 
































p> 




















J6, 





直到 集合 数据 发 生 








在 最 





划 。 
后 ， 


explain() 输 出 信 ， 
了 本 次 查询 尝试 过 的 每 个 查询 1 


5.3” 何 时 不 应 该 使 用 索 3 


提取 较 小 的 子 数 
些 碍 询 不 使 用 
占 的 比例 越 大 ， 索 引 的 速度 就 
引 需 要 进行 两 次 碍 # 





初 的 i 
变动 ， 


查询 优化 器 就 会 重 


十 划 评 估 之 后 集合 发 生 

















最 早 返 
的 查询 计划 就 


这 个 查询 接 下 来 都 会 使 
了 比较 大 的 变动 。 如 果 
了 比较 大 的 数据 


可 100 个 结 
会 被 中 止 。 
































aa 














查询 





建立 索引 时 ， 
优化 器 都 会 重新 





= j 


新 挑选 可 行 
或 者 是 每 执行 1 






































评估 查询 


息 里 的 "allPlans "字段 显示 
十 划 。 


的 查询 计 





000 次 查询 之 





FRI o 











据 集 时 ， 


索引 非常 亡 


高 效 。 也 有 一 

































































索引 会 更 








快 。 

















R: 





结果 集 在 原 集合 中 所 
越 慢 ， 因 为 使 用 案 
一 次 是 查找 索引 条 目 ， 

指针 去 查找 相应 的 文档 。 而 全 表 扫 




















AR: ARL. 








内 的 所 有 文档 ) ， 








在 最 坏 的 情 
使 用 索引 进行 




















H 














的 两 倍 ， 


效率 会 明显 比 























可 惜 ， 
何 根据 数据 大 小 、 
Sh 








P ARA-ARA A E 
索引 大 小 、 
的 平均 大 小 来 判断 什么 时 候 索 引 很 有 用 ， 
候 索引 会 降低 查询 速度 〈 如 表 5-1 所 示 ) 。 








文档 大 




















a a a 











比较 。 然而 ， 








影响 


说 ， 如 果 查 询 需 要 返回 
更 多 ) ， 那 就 应 该 对 索引 和 全 表 扫 
这 个 数字 可 能 会 











集合 内 30% 的 文档 (或 


诉 我 们 ， 如 
小 以 及 结果 
什么 


一 般 





















































蕴 的 速度 进 

















索引 效率 的 属性 


在 2% 一 60% 之 间 


























索引 通常 适用 的 情况 











全 表 扫 描 通 常 适 

















集合 较 大 





集合 较 小 





文档 较 大 


文档 较 小 





选择 性 查询 





非 选 择 性 查询 











假如 我 们 有 一 个 收集 统计 信 
定 账 户 去 系统 中 查询 所 
小 时 之 前 的 数据 生成 图 表 : 











>H 


星 序 要 根据 给 
据 从 初始 一 直到 











TA 





恩 的 分 析 














系统 。 应 用 
有 文档 ， 根 
































> db.entries.find({"created_at" 


: {"$1t" 








我 们 在 "created_at" | 


度 。 











初 运行 时 ， 结 果 


s 





非常 小 ， 





上 创建 索引 以 提 


BY LAN. 





高 查询 速 





即 返回 。 几 























星期 过 去 以 后 ， 数 据 开 始 多 起 来 了 ， 一 个 月 之 
， 这 个 查询 耗费 的 时 间 越 来 越 长 。 


对 于 大 部 分 应 用 程序 来 说 ， 这 很 可 

个 “错误 的 ”查询 : 真 的 需要 在 查询 中 返回 数据 集 
中 的 大 部 分 内 容 吗 ?大 部 分 应 用 程序 (尤其 是 拥 
有 非常 大 的 数据 集 的 应 用 程序 ) 都 不 需要 。 然 
而 ， 也 有 一 些 合理 的 情况 ， 可 能 需要 得 到 大 部 分 
或 者 全 部 的 数据 : 也 许 需 要 将 这 些 数据 导出 到 报 
表 系 统 ， 或 者 是 放 在 批量 任务 中 。 在 这 些 情况 
下 ， 应 该 尽 可 能 快 地 返回 数据 集中 的 内 容 。 


可 以 用 {"$natural"”: 1} 强 制 数据 库 做 全 表 扫 
描 。6.1 节 会 介绍 $natural， 它 可 以 指定 文档 按 
照 磁盘 上 的 顺序 排列 。 特 别 地 ，$natural 可 以 
强制 MongoDB 做 全 表 扫 描 : 


















































































































































































































































> db.entries.find({"created_at" : {"$1t" 



































使 用 "$natural" 排 序 有 一 个 副作用 : 返回 的 结 
果 是 按照 磁盘 上 的 顺序 排列 的 。 对 于 一 个 活跃 的 
集合 来 说 ， 这 是 没有 意义 的 : 随 着 文档 体积 的 增 
加 或 者 缩小 ， 文 档 会 在 磁盘 上 进行 移动 ， 新 的 文 
档 会 被 写 入 到 这 些 文档 留 下 的 空白 位 置 。 但 是 ， 
对 于 只 需要 进行 插入 的 工作 来 说 ， 如 果 要 得 至 
新 的 (或 者 最 早 的 ) 文档 ， 使 用 $natural 就 非 
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常 有 用 了 。 
54 索引 类 型 


创建 索引 时 可 以 指定 一 些 选 项 ， 使 用 不 同 选 项 建 
立 的 索引 会 有 不 同 的 行为 。 接 下 来 的 小 节 会 介绍 
常见 的 索引 变种 ， 更 高 级 的 索引 类 型 和 特殊 选项 


会 在 下 一 章 介绍 。 







































































5.4.1 ”唯一 索引 





唯一 索引 可 以 确保 集合 的 每 一 个 文档 的 指定 键 都 
有 唯一 值 。 例 如 ， 如 果 想 保证 同 不 文档 
的 "username" 刍 拥有 不 同 的 值 ， 创 建 一 个 唯 
索引 就 好 了 : 















































> db.users.ensureIndex({"username" : 1}, { 





























如 果 试 图 向 上 面 的 集合 中 插入 如 下 文档 : 




















> db.users.insert({username: "bob"}) 
> db.users.insert({username: "bob"}) 
£11000 duplicate key error index: test.use 
































如 果 检 查 这 个 集合 ， 会 发 现 只 有 第 一 个 "bob "被 
保存 进来 了 。 发 现 有 重复 的 侵 时 抛 出 异常 会 影 问 


















































效率 ， 所 以 可 以 使 用 唯一 索引 来 应 对 偶尔 可 能 会 
出 现 的 键 重复 问题 ， 而 不 是 在 运行 时 对 重复 的 键 
进行 过 滤 。 


有 一 个 唯一 索引 可 能 你 已 经 比较 熟悉 了 ， 就 

是 " id" 索引 ， 这 个 索引 会 在 创建 集合 时 自动 创 
建 。 这 就 是 一 个 正常 的 唯一 索引 (但 它 不 能 被 删 
除 ， 而 其 他 唯一 索引 是 可 以 删除 的 ) 。 


-3,, 个 文档 没有 对 应 的 键 ， 索 引 


会 将 其 作为 nul1 存 储 。 所 以 ， 如 果 对 某 个 键 建 
立 了 唯一 索引 ， 但 插入 了 多 个 缺少 该 索引 键 的 
文档 ， 由 于 集合 已 经 存在 一 个 该 索引 键 的 值 
为 null1 的 文档 而 导致 插入 失败 。5.4.2 节 会 详细 
介绍 相关 内 容 。 


有 些 情况 下 ， 一 个 值 可 能 无 法 被 索引 。 索 引 储 桶 
(index bucket) 的 大 小 是 有 限制 的 ， 如 果 某 个 索 
引 条 目 超 出 了 它 的 限制 ， 那 么 这 个 条 目 就 不 会 包 
含 在 索引 里 。 这 样 会 造成 一 些 困惑 ， 因 为 使 用 这 
个 索引 进行 查询 时 会 有 一 个 文档 凭空 消失 不 见 
了 。 所 有 的 字段 都 必须 小 于 1024 字 节 ， 才 能 包含 
到 索引 里 。 如 果 一 个 文档 的 字段 由 于 太 大 不 能 包 
含 在 索引 里 ，MongoDB 不 会 返回 任何 错误 或 者 警 















































































































































































































































































































































告 。 也 就 是 说 ， 超 出 8 KB 大 小 的 键 不 会 受到 唯一 
索引 的 约束 : 可 以 插入 多 个 同样 的 8 KB 长 的 字符 














1. 复合 唯一 索引 


也 可 以 创建 复合 的 唯一 索引 。 创 建 复合 唯一 索引 
时 ， 单 个 键 的 值 可 以 相同 ， 但 所 有 键 的 组 合 值 必 
须 是 唯一 的 。 


例如 ， 如 果 有 一 个 {"username" : 1, "age" 
1} 上 的 唯一 索引 ， 下 面 的 插入 是 合 法 的 : 







































































> db.users.insert({"username" : "bob"}) 
> db.users.insert({"username" : "bob", "ag 
> db.users.insert({"username" : "fred", "a 




















然而 ， 如 果 试 图 再 次 插入 这 三 个 文档 中 的 任意 一 
个 ， 都 会 导致 键 重复 异常 。 


GirdFS 是 MongoDB 中 存储 大 文件 的 标准 方式 〈 详 
见 6.5 节 ) ， 其 中 就 用 到 了 复合 唯一 索引 。 存 储 文 
件 内 容 的 集合 有 一 个 {"files_id" : 1, "n" : 
1} 上 的 复合 唯一 索引 ， 因此 文档 的 某 一 部 分 看 起 
来 可 能 会 是 下 面 这 个 样子 : 


|{"files id" : ObjectId("4b23c3ca7525f35f94 
























































{"files_id" : ObjectId("4b23c3ca7525f35f94 
{"files_id" : ObjectId("4b23c3ca7525f35f94 
{"files_id" : ObjectId("4b23c3ca7525f35f94 











注意 ， 所 有 "files_id" 的 值 都 相同 ， 但 是 "n" 的 
值 不 同 。 


2. 去 除 重 复 


在 已 有 的 集合 上 创建 唯一 索引 时 可 能 会 失败 ， 
为 集合 中 可 能 已 经 存在 重复 值 了 : 


> db.users.ensureIndex({"age" : 1}, {"uniq 
£11000 duplicate key error index: test.use 


























> 























































































































通常 需要 先 对 己 有 的 数据 进行 处 理 〈 可 以 使 用 聚 
合 框架 ) ， 找 出 重复 的 数据 ， 想 办 法 处 理 。 






































在 极 少数 情况 下 ， 可 能 希望 直接 删除 重复 的 值 。 
创建 索引 时 使 用 "dropDups" 选项 ， 如 果 遇 到 重 
复 的 值 ， 第 一 个 会 被 保留 ， 之 后 的 重复 文档 都 会 
被 删除 。 

















































































































> db.people.ensureIndex({"username" : 1}, 





























"dropDups" 会 强制 





性 建立 索引 ， 但 是 这 个 




















方式 太 粗 暴 了 : 你 无 法 控制 哪些 文档 被 保留 哪些 
文档 被 删除 〈 如 果 有 文档 被 删除 的 话 ，MongoDB 
也 不 会 给 出 提示 说 哪些 文档 被 删除 了 ) 。 对 于 比 
较 重 要 的 数据 ， 千 万 不 要 使 用 "dropDups"。 

































































5.4.2 RARI 


前 面 的 小 节 已 经 讲 过 ， 唯 一 索引 会 把 null 看 做 

值 ， 所 以 无 法 将 多 个 缺少 唯一 索引 中 的 键 的 文档 
插入 到 集合 中 。 然 而 ， 在 有 些 情况 下 ， 你 可 能 希 
望 唯一 索引 只 对 包含 相应 键 的 文档 生效 。 如 果 有 
一 个 可 能 存在 也 可 能 不 存在 的 字段 ， 但 是 当 它 存 
在 时 ， 它 必须 是 唯一 的 ， 这 时 就 可 以 将 unique 和 
sparse 选 项 组 合 在 一 起 使 用 。 






















































































ot MongoDB F RARI] (sparse 
index) 5 R RE iE E PR l ECA 
同 的 概念 。 基 本 上 来 说 ，MongoDB 中 的 稀疏 索 
引 只 是 不 需要 将 每 个 文档 都 作为 索引 条 目 。 


使 用 sparse 选 项 就 可 以 创建 稀 琉 索引 。 例 如 ， 如 
果 有 一 个 可 选 的 email 地 址 字段 ， 但 是 ， 如 果 提 供 














































































































了 这 个 字段 ， 





么 它 的 值 必须 是 唯一 的 : 








> db.ensureIndex({"email" 


: 1}, {"unique" 
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BL BY DA 2 — SEM — AS BEEZ So 

AR Th Fe MENAR AAAH 2 FR 

可 能 会 不 同 。 假如 有 这 样 一 个 Rea, FPA AMD 
分 文档 都 有 一 个 "x" 字 段 ， 但 是 有 些 没有 : 

> db.foo. .find() 

{ "_id" : @ } 

(oid? ed. Mx ae} 

CG id 4°25 "xX sp 2>} 

€ "id" :3 XT oe Be} 

当 在 "x" 上 执行 查询 时 ， 它 会 返回 相 匹配 的 文 

档 : 

> db.foo.find({"x" : {"$ne" : 2}}) 

{ "_id" : @ } 

{ "id" : 1, "x" : 1} 

{ "_id" : 3, "x" : 3 } 

WREX" EGU TBR "id" AON 

档 就 不 会 包含 在 索引 中 。 如 果 于 次 在 "x" 上 查 
















































































询 ，MongoDB 就 会 使 用 这 个 稀疏 索引 ，{ "id" 
: 8} 的 这 个 文档 就 不 会 被 返回 了 : 

> db.foo. Find({" x" : {"$ne" : 2}}) 

f “aidr 1 “act oat Le} 

{ "_id" : 3, "x" 3 } 

如 果 需 要 得 到 那些 不 包含 
































5.5 索引 管理 


使 用 hint() 强 制 进 行 全 表 扫 描 






































省 面 的 小 节 所 述 ， 
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一 次 。 如 果 重 复 
的 。 
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新 的 索引 。 对 于 一 个 旨 























创建 相 








所 有 的 数据 库 索引 信 





息 都 存储 














在 system.indexes 集 合 中 。 这 是 一 个 保 








合 ， 不 能 在 其 中 插入 或 者 删除 文档 。 只 能 通过 
ensureIndex 或 者 dropIndexes 对 其 进行 操作 。 














创建 一 个 索引 之 后 ， 就 可 以 在 system.indexes 
中 看 到 它 的 元 信息 。 可 以 执 
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行 db .collectionName.getIndexes() 来 查看 





给 定 集合 上 的 所 有 索引 信息 : 











可 以 使 用 ensuerIndex 函 数 
合 ， 每 个 索引 只 需要 
司 的 索引 ， 是 没有 任 














> db.foo.getIndexes() 


[ 
{ 


"id" : 1 


ns" : "test.foo", 
name" : ”id "” 


ns" : "test.foo", 
"x 1 y 1" 





























这 里 
























































被 当 作 标识 符 使 用 。 
是 多 键 索引 。 




















HoE 
指定 ee 在 这 里 ， 
{"x hn 


(比如 dropIndex)， 

















"v' a J 














果 你 的 索引 不 包含 


























最 重要 的 字段 是 "key" 和 "name"。 这 里 的 
在 hint、max、min 以 及 其 他 所 有 需要 
索引 的 顺序 很 重 
要 : y”: 1} 上 的 索引 与 {"y”: 
D ne": ay Raval. 对 于 很 多 的 索引 操 
作 








Lir 
Ta 











这 里 的 索引 名 称 都 可 以 

















旦 是 这 里 不 会 指明 索引 是 否 





]， 用 于 标识 案 引 版 本 。 如 
”: 1 这 样 的 字段 ， 说 明 你 


的 索引 是 以 一 种 效率 比 科 低 的 旧 方 式 在 依 的 。 将 





MongoDB 升 级 到 至 少 2.0 版 本 ， 





删除 并 重建 这 些 索 


= 





引 ， 就 可 以 把 索引 的 存储 方式 升级 到 新 的 格式 


了 。 


5.5.1 标识 索引 














作 索 引 。 




















(1 或 者 -1) 。 






































集合 中 的 每 一 个 索引 都 有 一 个 名 称 ， 用 于 唯一 标 
识 这 个 索引 ， 也 可 以 用 了 





服务 器 端 来 删除 或 者 操 
索引 名 称 的 默认 形式 是 key 
name1_dir1_keyname2_dir2_... 
其 中 KeynameX 是 索引 上 





_keynameN_d 


的 键 ，dirX 是 索引 的 方向 
如 果 索 引 中 包含 两 个 以 上 的 键 ， 这 
种 命名 方式 就 显得 比较 笨重 了 ， 好 在 可 以 














在 ensureIndex 中 指定 索引 的 名 称 : 








> db.foo.ensureIndex({"a" : 1, "b" : 1, "c 
. {"name" : "alphabet"}) 














索引 名 称 的 长 度 是 有 限制 的 ， 所 以 新 建 复杂 索引 
时 可 能 需要 自 定义 索引 名 称 。 调 
jgetLastError 就 可 以 知道 索引 是 否 成 功 创 
建 ， 或 者 失败 的 原因 。 






























































5.5.2 ”修改 索引 














随 着 应 用 不 断 增 长 变化 ， 你 会 发 现 数据 或 者 查询 
已 经 发 生 了 改变 ， 原 来 的 索引 也 不 那么 好 用 了 。 
这 时 可 以 使 用 dropIndex 命 令 删 除 不 再 需要 的 索 
5: 
























































> db.people.dropIndex("x_1_y_1") 
{ "nIndexesWas" : 3, "ok" : 1 } 





















































索引 描述 信息 里 "name" 字 段 的 值 来 指定 需要 删 
除 的 索引 。 


新 建 索 引 是 一 件 既 费 时 又 滔 费 资源 的 事情 。 默 认 
情况 下 ，MongoDB 会 尽 可 能 快 地 创建 索引 ， 阻 塞 
所 有 对 数据 库 的 读 请 求 和 写 请 求 ， 一 直到 索引 创 



















































































能 够 处 理 读 写 请 求 ， 可 以 在 
bc kground 选 项 。 这 上 f 
新 的 数据 库 请 求 需要 处 理 ， 
暂停 一 下 ， 但 是 仍然 会 对 应 用 程序 怕 

















建 完成 。 如 果 和 希望 数据 库 在 


| 建 索 引 的 同时 仍然 





























的 影响 (12.4.8 节 会 详细 介 


比 前 








第 18 章 会 更 详细 地 介绍 








台 创 建 索引 慢 得 多 。 
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当 上 创建 索引 会 比 六 


— && 


EE 








(ca) 











| 建 索引 时 指定 
建 索 引 时 ， 如 果 有 
| 建 索引 的 过 程 就 会 














能 有 比较 大 





绍 ) 。 后 台 创建 索引 














创建 索引 再 插入 














实际 创建 索引 。 


第 6 童 ” 特殊 的 索引 和 集合 


本 章 介 绍 MongoDB 中 一 些 特 殊 的 集合 和 索引 类 
型 ’ 包括 : 


类 队列 数据 的 固定 集合 (capped 
ollection) ; 
于 缓存 的 TIL 索引 ; 
se 

二 维 平面 和 球体 空间 的 地 理 空间 索引 ; 
a 


6.1 固定 集合 


MongoDB 中 的 “普通 ”集合 是 动态 创建 的 ， 而 且 可 
以 自动 增长 以 容纳 更 多 的 数据 。MongoDB 中 还 有 
另 一 种 不 同类 型 的 集合 ， 叫 做 固定 集合 ， 固 定 集 

合 需 要 事先 创建 好 ， 而 且 它 的 大 小 是 固定 的 《如 
图 6- 1 所 示 ) 。 说 到 固定 大 小 的 集合 ， 有 一 个 很 有 
趣 的 问题 : 向 一 个 已 经 满 了 的 固定 集合 中 插入 数 
据 会 怎么 样 ? 答案 是 ， 固 定 集合 的 行为 类 似 于 循 
环 队 列 。 如 果 已 经 没有 空间 了 ， 最 老 的 文档 会 被 
删除 以 释放 空间 ， 新 插入 的 文档 会 占据 这 块 空间 
(如 图 6-2 所 示 ) 。 也 就 是 说 ， 当 固定 集合 被 占 满 
时 ， 如 果 再 插入 新 文档 ， 固 定 集 合 会 自动 将 最 老 
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的 文档 从 集合 中 删除 。 


人 er 





图 6-1 新 文档 被 插入 到 队列 末尾 




















图 6-2 ”如 果 队 列 已 经 被 占 满 ， 那 么 最 老 的 文档 
会 被 之 后 插入 的 新 文档 覆盖 

















合 的 访问 模式 与 MongoDB 中 的 大 部 分 集合 
: 数据 被 顺序 写 入 磁盘 上 的 固定 空间 。 因 此 
EIRA (spinning disk) 上 的 写 入 速度 非 

















可 全 
































快 ， 尤 其 是 集合 拥有 专用 磁盘 时 〈 这 样 就 不 会 
为 其 他 集合 的 一 些 随机 性 的 写 操作 而 “中 
) 。 
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“固定 集合 不 能 被 分 片 。 


固定 集合 可 以 用 于 记录 日 志 ， 尺 管 它们 不 够 灵 
活 。 虽然 可 以 在 创建 时 指定 集合 小 ， 但 无 法 控 
制 什么 时 候 数据 会 被 覆盖 。 






























































6.1.1 创建 固定 集合 














不 同 于 普通 集合 ， 固 定 集合 必须 在 使 用 之 前 先 显 
式 创建 。 可 以 使 用 create 命 令 创 建 固定 集合 。 在 
shell 中 ， 可 以 使 用 createCollection 函 数 : 





























> db.createCollection("my_collection", {"c 
{ "ok" : true } 











为 100 000524 É 








上 面 的 命令 创建 了 一 个 名 my collection 大 小 
的 固定 集合 


除了 大 小 ，createCollection 还 能 够 指定 固定 
集合 中 文档 的 数量 


Es 











> db.createCollection("my_collection2", 
: true, "size" : 100000, "ma 


. {"capped" 


{ "ok" : true } 





























可 以 使 用 这 种 方式 来 保存 最 新 的 10 则 新 闻 ， 或 者 





























是 将 每 个 用 户 的 文档 数量 限制 为 1000。 


定 集合 创建 之 后 ， 就 不 能 改变 了 《如果 需 要 修 







































































FE 
四 
后 插入 的 新 文档 就 会 把 最 老 的 文 





必须 同时 指定 
一 个 限制 ， 之 
档 挤 出 集合 : 
档 数量 限制 ， 














司 定 集合 的 属性 ， 只 能 将 它 删 除 之 后 再 重 
) 。 因 此 ， 在 创建 大 的 固定 集合 之 前 应 该 仔 纪 


清楚 它 的 大 小 。 























il 














il 












































定 集合 指定 文档 数量 限制 时 ， 
定 集合 的 大 小 。 不 管 先 达到 哪 
































定 集合 的 文档 数量 不 能 超过 文 
定 集合 的 大 小 也 不 能 超过 大 小 








限制 。 


创建 固定 集合 时 还 有 另 一 个 选项 ， 可 以 将 已 有 的 
某 个 常规 集合 转换 为 固定 集合 ， 可 以 使 
jconvertToCapped 命 令 实现 。 下 面 的 例子 
将 test 集 合 转换 为 一 个 大 小 为 10 000 字 节 的 固定 
集合 : 
















































































> db.runCommand({"convertToCapped" : "test 
{ "ok" : true } 

















无 法 将 固定 集合 转换 为 非 固定 集合 (只 能 将 其 删 
除 ) 。 











6.1.2 ”自然 排序 





























对 固定 集合 可 以 进行 一 种 特殊 的 排序 ， 称 为 自然 
排序 (natural sort) 。 自 然 排序 返回 结果 集中 文 
档 的 顺序 就 是 文档 在 磁盘 上 的 顺序 〈 如 图 6-3 所 
示 ) 。 
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图 6-3 ”使 用 {"$natural" : 1} 进 行 排序 


对 大 多 数 集合 来 说 ， 自 然 排 序 的 意义 不 大 ， 因 为 
文档 的 位 置 经 常 变 动 。 但 是 ， 固 定 集合 中 的 文档 
是 按照 文档 被 插入 的 顺序 保存 的 ， 自 然 顺序 就 是 
文档 的 插入 顺序 。 因 此 ， 自 然 排序 得 到 的 文档 是 
从 旧 到 新 排列 的 。 当 然 也 可 以 按照 从 新 到 旧 的 顺 






















































































序 排列 〈 如 图 6-4 所 示 ) 。 











> db.my_collection.find().sort({"$natural" 














图 6-4 ”使 用 {"$natural"” : -1} 进 行 排序 


6.1.3 ”循环 游标 


循环 游标 Ctailable cursor) 是 一 种 特殊 的 游标 ， 
当 循 环 游 标的 结果 集 被 取 光 后 ， 游标 不 会 被 关 
闭 。 循 环 游标 的 灵感 来 自 tail -fme AAY 
标 跟 这 个 命令 有 点 儿 相 似 ) ， 会 尽 可 能 久 地 持续 
提取 输出 结果 。 由 于 循环 游标 在 结果 集 取 光 之 后 
不 会 被 关闭 ， 因 此 ， 当 有 新 文档 插入 到 集合 
时 ， 循 环 游标 会 继续 取 到 结 于 普通 集合 并 

E 护 文档 的 插入 顺序 ， 所 以 循环 游标 只 能 用 在 
固定 集合 上 。 











































































































































































































循环 游标 前 常用 于 当 文 档 被 插入 到 “工作 队 

实 就 是 个 固定 集合 》 时 对 新 插入 的 文档 
进行 处 理 。 如 果 超 过 10 分 钟 没有 新 的 结果 ， 循 环 
游标 就 会 被 释放 ， 因 此 ， 当 游标 被 关闭 时 自动 重 
新 执行 查询 是 非常 重要 的 。 下 面 是 一 个 在 PHP' 
使 用 循环 游标 的 例子 (不 能 在 mongo shell 中 使 用 
循环 游标 ) : 
































































































































$cursor = $collection->find()->tailable(); 


while (true) { 
if (!$cursor->hasNext()) { 
if ($cursor->dead()) { 
break; 


} 
sleep(1); 








else { 
while ($cursor->hasNext()) { 
do_stuff($cursor->getNext()); 
} 


} 
} 
































这 个 游标 会 不 断 对 查询 结果 进行 处 理 ， 或 者 是 等 
竺 新 的 查询 结果 ， 直 到 游标 被 关闭 (超过 10 分 钟 
没有 新 的 结果 或 者 人 为 中 止 查询 操作 ) 。 
























































6.1.4 没有 _iq 索 引 的 集合 





默认 情况 下 ， 每 个 集合 都 有 一 个 " id" 索引。 但 
是 ， 如 果 在 调用 createCollection 创 建 集合 时 
指定 autoIndexId 选 项 为 false， 创 建 集合 时 就 
不 会 自动 在 "_id" 上 创建 索引 。 实 践 中 不 建议 这 
么 使 用 ， 但 是 对 于 只 有 插入 操作 的 集合 来 说 ， 这 
确实 可 以 带 来 速度 的 稍 许 提升 。 


Do 了 一 个 没有 "id" 索 引 的 


集合 ， 那 就 永远 都 不 能 复制 它 所 在 的 mongod 
。 复 制 操作 要 求 每 个 集合 上 都 要 有 "”_id" 索 
5] FE j 操 作 ， 能 够 唯一 标识 集合 中 的 每 






























































































































































一 个 文档 


在 2.2 版 本 之 前 ， 
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旧版 的 回 



































能 够 填充 ” 
充 " 
dead" $e o 


记 住 ，"_id" 索 3 
RI 》 ie _id" RI 





固定 





是 非常 重要 的 ) 。 


合 默 认 是 没有 " 
式 地 将 autoIndexId 置 为 true。 如 果 


BE 


WN 








_id" 索 3 






































定 集合 ， 要 确保 你 的 应 用 程序 


_id" 字 段 KER 

















弓 动 填 





区 动 程 序 会 











使 用 ensureIndex 命 令 


令 创 








必须 是 唯一 索引 。 
Pues 











不 同 于 
IRT, 


























在 生产 环境 中 创建 
常 重要 的 。 所 以 创 
如 果 创建 的 " 
合 再 重建 了 。 


口 
































6.2 TTL 索引 




















H MRH 
更 加 灵活 的 老 
以 使 | 



































期 的 索引 ) ， 这 利 
个 超时 时 间 。 











一 个 文档 到 达 了 巴 
后 就 会 被 删除 。 这 种 类 
《比如 会 话 的 保存 ) 非常 有 用 


索引 之 前 先 E 


建 "” 




















id" 索引 必须 一 








mi ! 








_id" 索 引 不 合 规范 ， 就 只 能 删 





























除 集 





上 一 节 已 经 讲 过 ， 对 于 固定 集合 中 的 内 容 何 时 被 
有 非常 有 限 的 控 
化 移出 系统 〈age-out system) ， 可 
JTTLA4| (time-to-live index， 具 有 生命 周 
Fh 索引 允许 为 每 一 个 文 
预 设置 的 老 





制 权 限 。 如 果 需 要 


档 设置 一 
比 程度 之 
于 缓存 问题 












































在 ensureIndex 中 指定 expireAfterSecs 选 项 就 
可 以 创建 一 个 TIL 索引 : 


> // 超时 时 间 为 24 小 时 
> db.foo.ensureIndex({"lastUpdated" : 1}, 

















这 样 就 在 "lastUpdated" 字 7 段 上 建立 了 一 个 TTL 
索引 。 如 果 一 个 文档 的 "lastUpdated" 字 段 存在 
并 且 它 的 值 是 日 期 类 型 ， 当 服务 器 时 间 比 文档 
的 "1astUpdated" 字 段 的 时 间 

晚 expireAfterSecs 秒 时 ， 文 档 就 会 被 删除 。 


为 了 防止 活跃 的 会 话 被 删除 ， 可 以 在 会 话 上 有 活 
动 发 生 时 将 "lastUpdated" 字 上 段 的 值 更 新 为 当前 
时 间 。 只 要 "lastUpdated" 的 时 间距 离 当 前 时 间 
达到 24 小 时 ， 相 应 的 文档 就 会 被 删除 。 


MongoDB 每 分 钟 对 TTL 索 引进 行 一 次 清理 ， 所 以 
不 应 该 依赖 以 秒 为 单位 的 时 间 保 证 索引 的 存活 状 
态 。 可 以 使 用 collMod 命 令 修 
改 expireAfterSecs 的 值 : 






































































































































> db.runCommand({"collMod" : "someapp.cach 














在 一 个 给 定 的 集合 上 可 以 有 多 个 TTL 索 引 。TTL 
索引 不 能 是 复合 索引 ， 但 是 可 以 像 “ 普 通 ” 索 引 


















































样 月 
0.3 


MongoDB 有 


有 来 优化 排序 和 查询 。 
全 文本 索引 














个 特殊 类 型 














ALA 





























前 面 几 章 都 是 使 用 








En 









































JL 








式 来 查询 字符 串 ， 但 是 这 些 技术 有 一 些 限制 。 





的 索引 用 于 在 文档 
精确 匹配 和 正则 表达 











搜 
使 


FE 则 表达 式 搜索 大 块 文本 的 速度 非常 慢 ， 而 且 





















































无 法 处 理 语 言 的 理解 问题 〈 比 如 entry 与 entries 
该 算是 匹配 的 ) 。 使 用 全 文本 索引 可 以 非 











本 索引 的 成 本 更 高 。 





进行 文本 搜索 ， 就 如 同 内 置 
的 支持 一 样 。 


创建 任何 一 种 索引 的 开销 都 比较 大 ， 而 创建 全 文 
在 一 个 操作 频繁 的 集合 上 创 
建 全 文本 索引 可 能 会 导 致 MongoDB 过 载 ， 所 以 应 

















该 是 离线 状态 下 创建 全 文本 索引 ， 或 者 是 在 对 性 








了 多 种 语言 分 




















能 没 要 求 时 。 创 建 全 文本 索引 时 要 特别 小 


慎 ， 


章 会 介 














内 存 可 能 会 不 够 用 











降 至 最 低 。 





绍 如 何在 创建 索引 


BIA 





(除非 你 有 SSD) 。 
时 将 对 应 
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通 ” 索 引 更 严重 














问题 

















需要 被 分 解 、 
































忆 为 所 有 字符 串 者 
且 保存 到 一 些 地 方 。 由 
本 索引 的 集合 的 写 入 性 和 
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ne 


吊 局 
词 机 


< 二 











DA 
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制 | 
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LPT VE 





的 性 
分 词 ，3 


第 18 
程序 的 影响 

















可 能 会 发 现 拥 











其 他 集合 要 差 。 





EHA 











能 
并 
EM 
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入 、 








本 索引 也 会 降低 分 片 时 的 数据 迁移 速度 ， 将 数 
迁移 到 其 他 分 片 时 ， 所 有 文本 都 需要 重新 进行 索 
引 。 


写作 本 书 时 ， 全 文本 索引 仍然 只 是 一 个 处 于 “ 试 
验 阶 段 ” 的 功能 ， 所 以 需要 专门 启用 这 个 功能 
能 进行 使 用 。 启 动 MongoDB 时 指定 -- 
setParameter textSearch Enabled=true 选 
项 ， 或 者 在 运行 时 执行 setParameter 命 令 ， 都 
可 以 启用 全 文本 索引 : 


> db.adminCommand({"setParameter" : 1, "te 


HI 

















































































































假如 我 们 使 用 这 个 非 官方 的 Hacker News JSON 
API (http://api.ihackernews.com) 将 最 近 的 一 些 文 
章 加 载 到 了 MongoDB 中 。 


为 了 进行 文本 搜索 ， 首 先 需要 创建 一 个 "text" 索 
引 : 


> db.hn.ensureIndex({"title" : "text"}) 










































































现在 ， 必 须 通 过 text 命 令 才 能 使 用 这 个 索引 ( 写 
作 本 书 时 ， 全 文本 索引 还 不 能 用 在 “普通 ”查询 


P): 






































|test> db.runCommand({"text" : "hn", "searc| 





"queryDebugString" : "ask|hn||||||", 


"language" : "english", 
"results" : [ 
{ 
"score" : 2.25, 
"obj" : { 
"_id" : ObjectId("5@dcab29 
"title" : "Ask HN: Most va 
"url" : "/comments/4974230 
"id" : 4974230, 
"commentCount" : 37, 
"points" : 31, 
"postedAgo" : "2 hours ago 
"postedBy" : "bavidar" 
} 
}, 
{ 
"score" : 0.5625, 
"obj" : { 
"_id" : ObjectId("5@dcab29 
"title" : "Show HN: How I 
"url" : "http://www.howaca 
"id" : 4974055, 
"commentCount" : 44, 
"points" : 95, 
"postedAgo" : "2 hours ago 
"postedBy" : "AlexMuir" 













































































{ 
"score" : 0.5555555555555556, 
"obj" : { 
"_id" : ObjectId("5@dcab29 
"title" : "Show HN: ShotBl 
"url" "https://github.co 
"id" : 4973909, 
"commentCount" : 10, 
"points" : 17, 
"postedAgo" "3 hours ago 
"postedBy" "1@char" 
} 
} 
l 
"stats" : { 
"nscanned" : 4, 
"nscannedObjects" : 6， 
Sa 
"timeMicros" : 89 
J 
"ok" : 1 } 匹配 到 的 文档 是 按照 相关 性 降序 排列 
WJ: “Ask HN" 位 于 第 一 位 ， 然 后 是 两 个 部 分 匹 
配 的 文档 。 每 个 对 象 前 面 的 "score" 字 段 描述 了 
每 个 结果 与 查询 的 匹配 程度 。 
如 你 所 见 ， 这 个 搜索 是 不 区 分 大 小 写 不 的 ， 至 少 








对 于 [a-zA-Z] 这 些 字 符 是 这 样 。 全 文本 索引 会 


使 用 toLower 将 单词 
相关 的 ， 所 以 某 些 语言 的 用 





变 为 小 号 ， 但 这 是 与 本 地 化 


























站 可 能 会 发 现 


MongoDB 会 不 可 预测 性 地 变 得 区 分 大 小 写 ， 这 取 





决 于 toLower 在 不 同 





一 直 在 努力 提 











字符 集 上 的 行为 。MongoDB 
高 对 不 同 字 符 集 的 支持 。 








SAR TI 只 会 对 











字符 串 数 据 进行 索引 : 其 他 区 
数据 类 型 会 被 忽略 ， 不 会 包含 在 索引 中 。 一 个 自 











引 可 以 包含 多 个 字段 : 











Ay 





合 上 最 多 只 能 有 一 个 全 文本 索引 ， 但 是 全 文本 索 








> db.blobs.ensureIndex({"title" : "text", 


























与 “普通 ”的 多 键 索引 不 同 ， 全 文本 索引 中 的 字段 


E 





























顺序 不 重要 : 每 个 字段 都 被 同等 对 待 。 可 以 为 每 























个 字段 指定 不 同 的 权重 来 控制 不 同 字段 的 相对 重 

要 性 : 

> db.hn.ensureIndex({"title" : "text", "de 
. {"weights" : {"title" : 3, "author" 





默认 的 权重 是 1， 权 重 的 范围 

















可 以 是 1~1 000 000 


000。 使 用 上 面 的 代码 设置 权重 之 后 ，"title" 字 




















段 成 为 其 中 最 重要 的 字段 ， 
后 是 "desc" (没有 指定 ， 因 此 它 的 权重 是 默认 值 














"author" 其 次 ， 最 



































1) 。 


索引 一 经 创建 ， 就 不 能 改变 字段 的 权重 了 《除非 
删除 索引 再 重建 ) ， 所 以 在 生产 环境 中 创建 索引 
之 前 应 该 先 在 测试 数据 集 上 实际 操作 一 下 。 


对 于 某 些 集合 ， 我 们 可 能 并 不 知道 每 个 文档 所 包 
含 的 字段 。 本 aa "$**" 在 文档 的 所 有 字符 串 
字段 上 创建 全 文本 索引 : 这 不 仅 会 对 顶级 的 字符 
串 字 段 建立 索引 ， 也 会 搜索 骨 套 文档 和 数组 中 的 
字符 串 字 段 : 

























































































> db.blobs.ensureIndex({"$**" : "text"}) 





也 可 以 为 "$**" 设 置 权 重 : 





> db.hn.ensureIndex({"whatever" : "text"}, 
. {"weights" : {"title" : 3, "author" 




















"whatever" 可 以 指 代 任何 东西 。 在 设置 权重 时 
BAH 了 是 对 所 有 字段 进行 索引 ， 因 此 MongoDB 并 
不 要 求 你 明确 给 出 字段 列表 。 


















































6.3.1 搜索 语法 














默认 情况 下 ，MongoDB 会 使 用 OR 连接 查询 中 的 














每 个 词 : “ask OR hn”。 这 是 执行 全 文本 查询 最 有 
RHIN A 但 是 也 可 以 进行 短语 的 精确 匹配 ， 以 
及 使 用 NOT。 为 了 精确 查询 “ask hn”* 这 个 短语 ， 可 
以 用 双 引 号 将 查询 内 容 ; 括 起 来 ; 


> db.runCommand({text: "hn", search: "\"as 


{ 







































































"queryDebugString" : "ask|hn||||ask hn 
"language" : "english", 
"results" : [ 
{ 
score" 2.25, 
"obj" : { 
"_ id" : ObjectId("5@dcab29 
"title" : "Ask HN: Most va 
"url" : "/comments/4974230 
"id" : 4974230, 
"commentCount" : 37, 
"points" : 31, 
"postedAgo" : "2 hours ago 
"postedBy" : "bavidar" 
} 
} 
]， 
"stats" : { 
"nscanned" : 4, 
"nscannedObjects" : 0, 
A~ a Ly 








"nfound" : 1, 



































































































































"timeMicros" : 20392 

J 

"ok" : 1 
} 
这 比 使 用 OR 的 匹配 慢 一 些 ， 因 为 MongoDB 首 先 
要 执行 一 个 OR 匹 配 ， 然 后 再 对 匹配 结果 进行 
AND 匹 配 。 
可 以 将 查询 字符 串 的 一 部 分 指定 为 字面 量 匹配 ， 
另 一 部 分 仍然 是 普通 匹配 : 
> db.runCommand({text: "hn", search: "\"as 











这 会 精确 搜索 "ask hn" 这 个 短语 ， 也 会 可 选 地 
搜索 "ipod" 。 


也 可 








以 使 月 























索 结果 中 : 





A". 


"字符 指 








定 特定 的 词 不 要 出 现在 搜 











> db.runCommand({text: 


"hn", search: 


"-sta 





这 样 





就 会 返 


词 的 文档 。 





口 


























6.3.2 ”优化 全 文本 搜索 





匹配 “ve”* 但 是 不 包含 “startup” 这 个 




















有 几 种 方式 可 以 优化 全 文本 搜索 。 如 果 能 够 使 用 





























某 些 查询 条 件 将 搜索 结果 的 范围 变 小 ， 可 以 创建 























一 个 由 其 他 查询 条 们 


















































F 前 级 和 全 文本 字段 组 成 的 复 








> db.blog.ensureIndex({"date" : 1, "post" 











这 就 是 局 部 的 全 文本 索引 ，MongoDB 会 基于 上 面 
例子 中 的 "date" 先 将 搜索 范围 分 散 为 多 个 比较 小 








的 树 。 这 样 ， 对 于 特定 日 期 的 文档 进行 全 文本 碍 


询 就 会 快 很 多 了 。 











也 可 以 使 用 其 他 查询 条 












































牛 后 缀 ， 使 索引 能 够 覆盖 





























查询 。 例 如 ， 如 果 要 返 


ua 





"author" #ll"post" =~ 











段 ， 可 以 基于 这 两 个 字段 创建 一 个 复合 索引 : 








> db.blog.ensureIndex({"post" : "text", "a 





Hi SRAM Js RT SX te HSE EH: 














> db.blog.ensureIndex({"date" : 1, "post" 




















AD ATR S| PEAR Sl BAAS BY NE 











多 键 字段 。 


























创建 全 文本 索引 会 E 





动 /7 





集合 上 启 


















































所 以 不 要 禁用 它 。 











6.3.3 在 其 他 语言 中 搜索 








jusePower0f2Sizes 选 项 ， 这 个 选项 可 以 控 人 
空间 的 分 配方 式 。 这 个 选项 自 





= 


bE 够 提高 写 入 速度 ， 








当 一 个 文档 被 插入 之 后 《或 者 索引 第 一 次 被 创建 
之 后 ) ，MongoDB 会 查找 索引 字段 ， 对 字符 串 进 



































行 分 词 ， 将 其 减 小 为 一 个 基本 单元 〈essential 
unit) 。 然 后 ， 不 同 语言 的 分 词 机 制 是 不 同 的 ， 
所 以 必须 指定 索引 或 者 文档 使 用 的 语言 。 文 本 类 























型 的 索引 允许 指定 "default_language" 选 项 ， 
它 的 默认 值 是 "english"， 可 以 被 设置 为 多 种 其 
































语言 列表 ) 。 














他 语言 《MongoDB 的 在 线 文档 提供 了 最 新 的 支持 











例如 ， 要 创建 一 个 法 语 的 索引 ， 可 以 这 么 做 : 








> db.users.ensureIndex({"profil" : "text", 
... {"default_language" : 


"french"}) 





这 样 ， 这 个 索引 就 会 默认 使 








除非 指定 了 其 他 的 分 词 机 制 。 




















] 法 语 的 分 词 机 制 





























如 果 在 插入 文档 时 








指定 "language" 字 段 ， 就 可 以 为 每 个 文档 分 别 

















指定 分 词 时 使 用 的 语言 : 











"profile" 





> db.users.insert({"username" 


"Bork de bork", 


"swedishCh 
language : 





6.4 ”地 理 空 











地 图 ) 和 2d 索 引 
H) 。 











2dsphere 人 允许 使 用 
Chttp://www.geojs 











点 可 以 用 
度 ]) 





形 。 
(AB, 4 


{ 





"name" 
"loc" : { 
"type" 





HRI 


MongoDB 文 持 几 种 类 型 
常用 的 是 2dsphere 索 引 ( 


"coordinates" 














J 的 地 理 空 




















s 间 索引 。 其 
于 地 球 表面 类 型 








Hı 








最 
的 
































《用 于 平面 














GeoJSON 格 式 








"New York City", 


"Point", 
: [50, 2] 





也 图 和 时 间 连 续 的 数 


on.org) 指定 点 、 线 和 多 边 
形 如 [Longitude，, Latitude] 
的 两 个 元 素 的 数组 表示 : 























] 一 个 由 点 组 成 的 数组 来 表示 : 





"name" 


"Hudson River", 








"loc" : { 
"type" : "Line", 
"coordinates" : [[@,1], [0,2], [1, 


} 


多 边 形 的 表示 方式 与 线 一 样 〈 都 是 一 个 由 点 组 成 
的 数组 ) ， 但 是 "type" 不 同 : 


















































{ 
"name" : “New England", 
"loc" : { 
"type" : "Polygon", 
"coordinates" : [[@,1], [0,2], [1, 
} 
} 

















"loc" 字 上 段 的 名 字 可 以 是 任意 的 ， 但 是 其 中 的 子 
对 象 是 由 GeoJSON 指 定 的 ， 不 能 改变 。 



































在 ensureIndex 中 使 用 "2dsphere" 选 项 就 可 以 
创建 一 个 地 理 空间 索引 : 


> db.world.ensureIndex({"loc" : "2dsphere" 
























































6.4.1 地理 空 间 查 询 的 类 型 















































可 以 使 用 多 种 不 同类 型 的 地 理 空 间 查 询 : 交集 
Cintersection) 、 包 含 〈within) 以 及 接近 
(nearness) 。 查 询 时 ， 需 要 将 希望 查找 的 内 容 
指定 为 形 如 {"$geometry"” : geoJsonDesc} 的 
GeoJSON 对 象 。 









































例如 ， 可 以 使 用 "$geoIntersects "操作 符 找 出 
与 查询 位 置 相 交 的 文档 : 


> var eastVillage = { 
"type" : "Polygon", 
"coordinates" : [ 
. [-73.9917900, 40.7264100], 
. [-73.9917900, 40.7321400], 
. [-73.9829300, 40.7321400], 
. [-73.9829300, 40.7264100] 
su ie 
> db.open.street.map. find( 
. {"loc" : {"$geoIntersects" : {"$geomet 


























这 样 就 会 找到 所 有 与 East Village 区 域 有 交集 的 文 
档 。 


可 以 使 用 "$within" 查 询 完全 包含 在 某 个 区 域 的 
文档 ， 例 如 : “East Village 有 哪些 餐馆 ? ” 



























































> db.open.street.map.find({"loc" : {"$with 

















与 第 一 个 查询 不 同 ， 这 次 不 会 返 
East Village《〈 比 如 街道 ) 或 者 部 分 
于 表示 曼哈顿 的 多 边 形 ) 的 文档 。 


最 后 ， 可 以 使 用 "$near" 查 询 附 近 的 位 置 : 
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> db.open.street.map.find({"loc" : {"$near 














注意 ，"$near" 是 唯一 一 个 会 对 查询 结果 进行 自 
动 排序 的 地 理 空间 操作 符 : "$near" 的 返回 结 
是 按照 距离 由 近 及 远 排 序 的 。 


地 理 位 置 查 询 有 一 点 非常 有 趣 : 不 需要 地 理 空间 
索引 就 可 以 使 用 "$geoIntersects" 或 
者 "$within" ("$near" 需 要 使 用 索引 ) 。 但 
是 ， 建议 在 | 于 表示 地 理 位 置 的 F 段 上 建立 地 十 
空间 索引 ， 这 样 可 以 显著 提高 查询 速度 。 
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6.4.2 ”复合 地 理 空 间 索 引 






































如 果 有 




















他 类 型 的 索引 ， 可 以 将 地 理 空间 索引 与 
其 他 字段 组 合 在 一 起 使 用 ， 以 便 对 更 复杂 的 查询 
进行 优 上 面 提 到 过 一 种 可 能 的 查询 : “East 

Village 有 哪些 餐馆 ? ”。 如 果 仅 仅 使 用 地 理 空间 索 
引 ， 我 们 只 能 查找 到 East Village 内 的 所 有 东西 ， 
但 是 如 果 要 将 “restaurants” 或 者 是 “pizza” 单 独 查询 


























a" 5 I 






















































































出 来 ， 就 需要 使 用 其 他 索引 














中 的 字段 了 : 








> db.open.street.map.ensureIndex({"tags" 








然后 就 能 够 很 快 地 找到 East Village 内 的 披萨 店 











T: 











"tags" 


> db.open.street.map.find({"loc" 
"pizza"}) 


: {"$with 


















































YE. MZA 
段 放 在 前 面 。 





6.4.3 2D 索引 









































， 这 取决 于 我 们 希望 


其 他 索引 字段 可 以 放 在 "2dsphere" 字 段 前 面 也 
Ay DATE JE E 
索引 的 字段 进行 过 滤 还 是 首先 使 用 
了 个 能 够 过 滤 掉 尽 可 能 多 的 结果 的 字 





于 先 使 用 其 他 
位 置 进 行 过 
































































































































对 于 非 球 面 地 图 (游戏 地 图 、 时 间 连 续 的 数据 
等 ) ， 可 以 使 用 "2d" 索 引 代 替 "2dsphere'": 

> db.hyrule.ensureIndex({"tile" "2d"}) 
"2d" 索 引用 于 扁平 表面 ， 而 不 是 球体 表 

面 。"2d" 索 引 不 应 该 用 在 球体 表面 上 ， 和 否则 极点 
附近 会 出 现 大 量 的 扭曲 变形 。 





















































文档 中 应 该 使 用 包含 两 个 元 素 的 数组 表示 2d 索 引 
字段 〈 写 作 本 书 时 ， 这 个 字段 还 不 是 GeoJSON 文 











ED 。 示 例如 下 : 

{ 
"name" : "Water Temple", 
"tile" : [ 32, 22 ] 

} 




















"2d" 索 引 只 能 对 点 进行 索引 。 可 以 保存 一 个 由 点 





IDNA 














组 成 的 数组 ， 但 是 它 只 会 被 保存 为 由 点 组 成 的 数 
组 ， 不 会 被 当成 线 。 特 别 是 对 于 "$within" 查 询 



































这 是 一 项 重要 的 区 别 。 如 果 将 街道 保存 为 
































成 的 数组 ， 那 么 如 果 其 中 的 某 个 点 位 于 给 








定 的 形状 之 内 ， 这 个 文档 就 会 与 $bwithin 相 匹 























[x 




















日 是 ， 由 这 些 点 组 成 的 线 并 不 一 定 完全 包含 














默认 情 














况 下 ， 地 理 空间 索引 是 假设 你 的 值 都 介 





于 -180~180。 可 以 根据 需要 在 ensureIndex 中 设 






































置 更 大 或 者 更 小 的 索引 边界 值 ; 











> db.star.trek.ensureIndex({"light-years" 





会 创 





H 








建 一 个 2000x2000 大 小 的 空间 索引 。 
































使 用 "2d" 索 引进 行 查询 比 使 用 "2dsphere" 要 简 









































单 许多 。 可 以 直接 使 用 "$near" 或 
者 "$within"， 而 不 必 带 有 "$geometry" 子 对 
象 。 可 以 直接 指定 坐标 : 


> db.hyrule.find({"tile" : {"$near" : [20, 
























































这 样 会 返回 hyrule 集 合 内 的 全 部 文档， 按照 距离 
(20,21) 这 个 点 的 距离 排序 。 如 果 没 有 指定 文档 数 
量 限制 ， 默认 最 多 返回 100 个 文档 。 如 果 不 需要 
这 么 多 结果 ， 应 该 根据 需要 设置 返回 文档 的 数量 
以 节省 服务 器 资源 。 例 如 ， 下 面 的 代码 只 会 返 
距离 (20,21) 最 近 的 10 个 文档 : 
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prd 



































> db.hyrule.find({"tile" : {"$near" : [20, 














"$within" J JEWHEN GEW, HEE 
者 是 多 边 形 ) WANA SCR. WREE HE 
形 ， 可 以 指定 "$box" 选 项 : 


> db.hyrule.find({"tile" : {"$within" : {" 










































































"$box" 接 受 一 个 两 元 素 的 数组 ， 第 一 个 元 素 指定 
左下 角 的 坐标 ， 第 二 个 元 素 指定 上 角 的 坐标 。 


类 似 地 ， 可 以 使 用 "$center" 选 项 返回 圆 形 范 围 
内 的 所 有 文档 ， 这 个 选项 也 是 接受 一 个 两 元 素数 




























































































组 作为 参数 : 第 一 个 元 素 是 一 个 点 ， 用 于 指定 贺 
心 ; 第 二 个 参数 用 于 指定 半径 : 


> db.hyrule.find({"tile" : {"$within" : {" 



































SS 


还 可 以 使 用 多 个 点 组 成 的 数组 来 指定 多 边 


> db.hyrule.find( 
. {"tile" : {"$within" : {"$polygon" : [ 























这 个 例子 会 查询 出 包含 给 定 三 角形 内 的 点 的 所 有 
文档 。 列 表 中 的 最 后 一 个 点 会 被 连接 到 第 一 个 
点 ， 以 便 组 成 多 边 形 。 


6.5 ”使 用 GridFS 存 储 文件 


GridFS 是 MongoDB 的 一 种 存储 机 制 ， 用 来 存储 大 
型 二 进 制 文件 。 下 面 列 出 了 使 用 GridFS 作 为 文件 
存储 的 理由 。 


。 使 用 GridFS 能 够 简化 你 的 栈 。 如 果 已 经 在 使 

用 MongoDB， 那 么 可 以 使 用 GridFS 来 代替 独 
立 的 文件 存储 工具 。 

。 GridFS 会 自动 平衡 已 有 的 复制 或 者 为 
MongoDB 设 置 的 自动 分 片 ， 所 以 对 文件 存储 
做 故障 转移 或 者 横向 扩展 会 更 容易 。 
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于 存储 用 户 








上 传 的 文人 











到 





比较 从 容 地 解 RA 
的 问题 。 例 如 ， 在 GridFS 文 件 系 统 : 
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也 一 些 文件 





























果 在 同 


何 问 题 。 





个 目录 下 存储 大 量 


E EHI 文件 , 


EHT, GridFS 
系统 可 能 





可 
会 




















没有 任 


TT 

















K 
件 的 











GridFS 也 有 一 些 





e GridFS 的 性 


fe, FA 
快 。 





。 如 果 要 修改 GridFS 上 的 文档 
文档 删除 ， 然 后 再 将 整个 文档 
MongoDB 将 文 
以 它 无 法 在 同一 时 间 对 文件 中 


锁 。 


HKD, 
eS 
> 

















6.5.1 GridF 


在 GridFS: 


渎 访问 的 大 文件 











“缺点 。 














[直接 从 文件 
































E 比 较 低 :从 MongoDB 中 
系统 中 访问 文件 i 


， 只 能 先 ; 





， 文 件 存储 的 集中 度 会 比较 高 ， 


为 MongoDB 是 以 2 GB 为 单位 来 分 配 数据 文 


访问 文 
速度 


各 已 有 








an 

















SATII 


作为 多 个 文档 


[ 果 你 有 一 些 不 常 改变 但 
» BAK 














重新 保存 。 
进行 存 
的 所 有 块 加 


ii, FT 























JGridFS 


























使 用 GridFS 最 简单 的 方式 是 使 用 mongofiles 工 
具 。 所 有 的 MongoDB 发 行 版 中 都 包含 了 

mongofiles， 可 以 用 它 在 GridFS 中 上 传 文件 、 
下 载 文件 、 查 看 文件 列表 、 搜 索 文件 ， 以 及 删除 
Me 牛 。 

































































与 其 他 的 命令 行 工具 一 样 ， 运 行 mongofiles -- 
help 就 可 以 查看 它 的 可 用 选项 了 。 


在 下 面 这 个 会 话 中 ， 首 先 用 mongofiles 从 文件 
系统 中 上 传 一 个 文件 到 GridFS， 然 后 列 出 GridFS 
中 的 所 有 文件 ， 最 后 再 将 之 前 上 传 过 的 文件 从 
GridFS 中 下 载 下 来 : 


$ echo "Hello, world" > foo.txt 

$ ./mongofiles put foo.txt 

connected to: 127.0.0.1 

added file: { _id: ObjectId('4c@d2a6c3052c 
filename: "foo.txt", lengt 
uploadDate: new Date(12759 
md5: "a7966bf58e23583c9a5a 























































































































done! 

$ ./mongofiles list 
connected to: 127.0.0.1 
foo .txt 13 

$ rm foo.txt 

$ ./mongofiles get foo.txt 
connected to: 127.0.0.1 








done write to: foo.txt 
$ cat foo.txt 
Hello,world 























在 上 面 的 例子 中 ， 使 用 mongofiles 执 行 了 三 种 

基本 操作 : put、1ist 和 get。put 操 作 可 以 将 文 
件 系统 中 选 定 的 文件 上 传 到 GridFS; 1ist 操 作 可 
以 列 出 GridFS 中 的 文件 ，get 操 作 与 put 相 反 ， 用 
于 将 GridFS 中 的 文件 下 载 到 文件 系统 
中 。mongofiles 还 支持 另外 两 种 操作 : 用 于 在 

GridFS 中 搜索 文件 的 search 操 作 和 用 于 从 GridFS 
中 删除 文件 的 delete 操 作 。 
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6.5.2 ”在 MongoDB 驱 动 程序 中 使 用 GridFS 


























所 有 客户 端 驱动 程序 都 提供 了 GridFS API。 例 
如 ， 可 以 用 PyMongo (MongoDB 的 Python 驱动 程 
Fe) 执行 与 上 面 直接 使 用 mongofiles 一 样 的 操 
作 : 





















































>>> from pymongo import Connection 

>>> import gridfs 

>>> db = Connection().test 

>>> fs = gridfs.GridFS(db) 

>>> file id = fs.put("Hello, world", filen 
>>> fs.list() 








[u'foo.txt'] 
>>> fs.get(file_id).read() 
"Hello, world' 





PyMongo 中 用 于 操作 GridFS 的 API 与 nongofiles 
非常 像 : 可 以 很 方便 地 执行 put、get 和 1ist 操 

作 。 几 乎 所 有 MongoDB 驱 动 程序 都 遵循 这 种 基本 
模式 对 GridFS 进 行 操作 ， 当 然 通常 也 会 提供 一 些 
更 高 级 的 功能 。 关 于 特定 驱动 程序 对 GridFS 的 操 
作 ， 可 以 查询 相关 驱动 程序 的 文件 。 






























































6.5.3 揭 开 GridFs 的 面纱 























GridFS 是 一 种 轻 量 级 的 文件 存储 规范 ， 于 存储 
MongoDB 中 的 普通 文档 。MongoDB 服 务 器 几乎 不 
会 对 GridFS 请 求 做 “特殊 ”处 理 ， 所 有 处 理 都 由 客 
户 端 的 驱动 程序 和 工具 负责 。 


GridFS 背 后 的 理念 是 : 可 以 将 大 文件 分 割 为 多 个 
比较 大 的 块 ， 将 每 个 块 作为 独立 的 文档 进行 存 
浇 。 由 于 MongoDB 支 持 在 文档 中 存储 二 进 制 数 
据 ， 所 以 可 以 将 块 存储 的 开销 降 到 非常 低 。 除 了 
将 文件 的 每 一 个 块 单独 存储 之 外 ， 还 有 一 个 文档 
于 将 这 些 块 组 织 在 一 起 并 存储 该 文件 的 元 信 



































































































































































































































GridF 








集合 。 
SEN 


























S 中 的 块 会 被 存储 到 专用 的 集合 中 。 块 默认 








使 用 的 集合 是 fs.chunks， 不 过 可 以 修改 为 其 他 























{ 


} 





在 块 集合 内 部 ， 各 个 文档 的 结构 非常 简 
"id" : ObjectId("..."), 
"D": O, 
"data" : BinData("..."), 
"files id" : ObjectId("...") 





与 其 他 的 MongoDB 文 档 一 样 ， 块 也 都 拥有 一 个 唯 
一 的 


























_id"。 另 外 ， 还 有 如 下 几 个 键 。 


e "files_ id" 


块 所 属 文件 的 元 信息 。 


"p" 
块 在 文件 中 的 相对 位 置 。 


e "data" 


块 所 包含 的 二 进 制 数据 。 




































































每 个 文件 的 元 信息 被 保存 在 一 个 单独 的 集合 中 ， 


默认 情况 下 这 个 集合 是 fs .files。 这 个 文件 自 


























A 





AFE 


的 每 一 个 文档 表示 GridFS 中 的 一 个 文件 ， 文 




















档 中 可 以 包含 与 这 个 文件 相关 的 任意 用 户 自 定义 
元 信息 。 除 用 户 自 定义 的 键 之 外 ， 还 有 几 个 键 是 
GridFS 规 范 规定 必须 要 有 的 。 












































e "id" 
文件 的 唯一 id， 这 个 值 就 是 文件 的 每 个 块 文 
档 中 "files_id" 的 值 。 











e "length" 
文件 所 包含 的 字 节 数 。 





e "chunkSize" 
组 成 文件 的 每 个 块 的 大 小 ， 单 位 是 字 节 。 这 
个 值 默 认 是 256 KB， 可 以 在 需要 时 进行 调 
整 。 


























e "uploadDate" 
文件 被 上 传 到 GridFS 的 日 期 。 





e "md5" 

文件 内 容 的 md5 校 验 值 ， 这 个 值 由 服务 器 端 
计算 得 到 。 

这 些 必须 字段 中 最 有 意思 〈 或 者 说 能 够 见 名 知 

意 ) 的 一 个 可 能 是 "md5"。 "md5" 字 段 的 值 是 

MongoDB 服 务 器 使 用 filemd5 命 令 得 到 的 ， 这 个 



















































































命令 可 以 用 来 计 





值 。 





这 意 味 着 , 





用 户 可 以 通 

















验 值 来 确保 文件 上 传 正 确 。 














LE Le BI GridF SA 





面 所 说 ， 在 fs.files 中 ， 除 了 这 





















































任何 自 定义 的 字 
可 能 你 希望 在 文 从 
F 载 次 数 、MIME 类 型 或 者 月 














平分 。 





的 块 的 md5 校 验 
过 检查 文件 的 


md5 校 


些 必须 字 
段 来 保存 必需 的 
元 信息 中 保存 文 
va 





只 要 理解 了 GridFS 底 层 的 规范 ， 





FH Hy HL — wey 











自己 就 可 


o 








KIEF A hetk 














的 











助 功 

















如 ， 可 以 使 用 d 














istinct 命 令 得 











的 ) 。 


到 GridFS 
件 的 文件 名 集合 (集合 中 的 每 个 文 伯 





以 很 容 


能 。 例 











保存 文 








名 都 是 唯一 








> db.fs.files.distinct("filename") 
[ "foo.txt" , "bar.txt" , "baz.txt" ] 








这 样 ， 在 加 载 或 者 收集 文 伯 
有 非常 大 的 灵活 











Fp ay LAF 


























性 。 





相关 信息 时 ， 应 用 程 








第 7 章 BRA 














































































































































































































2K A 
如 果 你 有 数据 存储 在 MongoDB 中 ， 你 ; iar uals 
就 不 仅仅 是 将 数据 提取 出 来 那么 简单 了 ; 
希望 对 数据 进行 分 析 并 加 以 利用 。 本 章 介 
MongoDB 提 供 的 聚合 工具 : 
° 聚合 框架 ; 
e MapReduce; 
。 几 个 简单 聚合 命令 : count, distinct fil 
group. 
7.1 聚合 框架 
使 用 聚合 框架 可 以 对 集合 中 的 文档 进行 变换 和 组 
合 。 基 本 上 ， 可 以 用 多 个 构件 创建 一 个 管道 
(pipeline) ， 用 于 对 一 连 串 的 文档 进行 处 理 。 这 
些 构 件 包括 筛选 (filtering)〉 、 投 射 
(projecting) 、 分 组 (grouping) 、 排 序 
(sorting) 、 限 制 (limiting〉 和 跳 过 
(skipping) 。 
例如 ， 有 一 个 保存 着 杂志 文章 的 集合 ， 你 可 能 希 
望 找 出 发 表 文 章 最 多 的 那个 作者 。 假 设 每 篇 文章 


被 保存 为 MongoDB 中 的 一 


个 文档 ， 可 以 按照 如 下 





1. 将 每 个 文章 文档 中 的 作者 投射 出 来 。 

2. 将 作者 按照 名 字 排 序 ， 统 计 每 个 名 字 出 现 的 
次 数 。 

3. 将 作者 按照 名 字 出 现 次 数 降序 排列 。 

4. 将 返回 结果 限制 为 前 5 个 。 


这 里 面 的 每 一 步 都 对 应 聚合 框架 中 的 一 个 操作 


Ay: 
























































1. {"$project" : {"author" : 1}} 


这 样 可 以 将 "author" 从 每 个 文档 中 投射 出 
来 。 





这 个 语法 与 查询 中 的 字段 选择 器 比较 像 ， 可 
以 通过 指定 "fieLdname"” : 1 选择 需要 投射 
的 字段 ， 或 者 通过 指定 "FieLdname" :6 排除 
不 需要 的 字段 。 执 行 完 这 个 "$project" 操 

作 之 后 ， 结 果 和 集中 的 每 个 文档 都 会 以 {"_id" 































































































: id, "author" : "quthorName"} 这 样 
的 形式 表示 。 这 些 结果 只 会 在 内 存 中 存在 ， 
\ 会 被 写 入 磁盘 。 


2. {"$group" : {"_id" : "$author", 


"count" : {"$sum" : 1}}} 


这 样 就 会 将 作者 按照 名 字 排 序 ， 某 个 作者 的 
名 字 每 出 现 一 次 ， 就 会 对 这 个 作者 
的 "count" 加 1。 









































这 里 首先 指定 了 需要 进行 分 组 的 字 
段 "author"。 这 是 由 "_id" : 
"$author" 指 定 的 。 可 以 将 这 个 操作 想象 
为 : 这 个 操作 执行 完 后 ， 每 个 作者 只 对 应 一 
个 结果 文档 ， 所 以 "author" 就 成 了 文档 的 
唯一 标识 符 ("_id") 。 

第 二 个 字段 的 意思 是 为 分 组 内 每 个 文档 
的 "count' ' 字 段 加 1。 注意 ， 新 加 入 的 文档 


并 不 会 有 "count "字段 ; 这 "$group" 创 建 的 
一 个 新 字段 。 


执行 完 这 一 步 之 后 ， 结 果 集中 的 每 个 文档 会 
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z Sim 





















































是 这 样 的 结构 : {"_id" : "authorName", 
"count" : articleCount}. 
. {"$sort" : {"count" : -1}} 





这 个 操作 会 对 结果 集中 的 文档 根 
据 "count" 字 段 进 行 降 序 排列 。 








4. {"$limit" : 5} 



















































































这 个 操作 将 最 终 的 返回 结果 限制 为 当前 结 
中 的 前 5 个 文档 。 
在 MongoDB 中 实际 运行 时 ， 要 将 这 些 操作 分 
别传 给 aggregate() 函 数 : 
> db.articles.aggregate({"$project" 
... {"$group" : {"_id" : "$author", "c 
.. {"$sort" : {"count" : -1}}, 
wee {"$limit" : 5}) 
{ 
"result" : [ 
{ 
"id" : "R. L. Stine", 
"count" : 430 
J 
{ 
"_id" "Edgar Wallace", 
"count" : 175 
J 
{ 
"_id" "Nora Roberts", 
"count" : 145 
}, 
{ 
"_id" "Erle Stanley Gard 
"count" : 140 








}, 
{ 
"id" : "Agatha Christie", 
"count" : 85 
} 
ok" :1 
} 

















aggregate() 会 返回 一 个 文档 数组 ， 其 中 的 
内 容 是 发 表 文 章 最 多 的 5 个 作者 。 


Va 














他 ,如 果 管 道 没有 给 出 预期 的 结果 ， 就 
需要 进行 调试 ， 调 试 时 ， 可 以 先 只 指定 第 一 个 
管道 操作 符 。 如 果 这 时 得 到 了 预期 结果 ， 那 就 
再 指定 第 二 个 管道 操作 符 。 以 前 面 的 例子 来 
说 ， 首 先 要 试 着 只 使 用 "$project" 操 作 符 进 
行 聚合 ， 如 果 这 个 操作 符 的 结果 是 有 效 的 ， 就 
再 添加 "$group" 操作 符 ; 如 果 结 果 还 是 有 效 
的 ， 就 再 添加 "$sort"; 最 后 再 添 

加 "$1Limit" 操 作 符 。 这 样 就 可 以 逐步 定位 到 
造成 问题 的 操作 符 。 






























































































































































































































































本 书写 作 时 ， 聚 合 


作 ， 
Gi 

















KERA 2 
的 结果 必须 要 
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7.2 


每 个 操作 符 都 会 接受 
些 类 型 转换 ， 最 后 将 转换 后 的 文档 


做 一 


的 最 大 响应 消息 








结果 必须 返 下 
民 制 在 16 MB 以 内 
息 大 小 ) 














管道 操作 符 





传递 给 下 一 个 操 


符 ， 


不 同 的 管道 操作 符 可 以 按 和 


串 的 文档 ， 





连 





cee 

















MERE Ont 


E 架 还 不 能 对 集合 
给 客户 端 。 





进行 写 入 操 
PUA, R 
MongoDB 3% 


对 这 些 文档 
作为 结果 
































于 最 后 一 个 管道 操作 























是 将 结果 返 
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7.2. 


$match 月 
筛选 得 到 
Oregon (AIH, fii AOR) 的 上 


Jr 





而 且 可 以 被 
$m 


$match" 





询 条 件 ) 。 


1 $match 








的 文档 











就 


可 以 使 月 
"OR"}}。 





"$mat 


有 于 对 文档 集合 进 和 


H{$match : 





nl? 


从 客户 端 ) 。 
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ERM 














PAGE 
F 意 多 次 。 例 如 ， 可 以 先 
atch"， 然 后 做 "$group"， 然 后 再 
(与 之 前 的 "$match" 匹 本 


起 使 


























UN 








TSize, 


聚合 。 


子 集 上 做 





Nis 


例如 ， 


二 后 就 可 以 在 
如 果 想 对 














{"state" 
以 使 月 











ch" 可 

















j 户 做 统计 ， 


所 有 常规 的 查询 操 





村 《〈"$ "$1lt"、"$in" 等 ) 。 有 一 个 例外 
需要 注意 :不 能 在 "$match" 中 使 用 地 理 空间 操 















































通常 ， 在 实际 使 用 中 应 该 尽 可 能 将 "$match" 放 

在 管道 的 前 面 位置 。 这 样 做 有 两 个 好 处 一 是 可 
快速 将 不 需要 的 文档 过 滤 掉 ， 以 减少 管道 的 工 

作 量 ， 二 是 如 果 在 投射 和 分 组 之 前 执 

行 "$ 

































































match"， 查 询 可 以 使 用 索引 。 











7.2.2 Sproject 


相对 于 “普通 ”的 查询 而 言 ， 管 道中 的 投射 操作 更 
加 强大 。 使 用 "$project" 可 以 从 子 文档 中 提取 

字段 ， 可 以 重 命名 字段 ， 还 可 以 在 这 些 字段 上 进 
行 一 些 有 意思 的 操作 。 


AE ee AETA 

要 的 字段 。 可 以 指定 包含 或 者 不 包含 一 个 字 
它 的 语法 与 查询 中 的 第 二 个 参数 类 似 。 如 果 
在 原来 的 集合 上 执行 下 面 的 代码 ， 返 回 的 结果 文 
档 中 只 包含 一 个 "author" 字 段 。 
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> db.articles.aggregate({"$project" : {"au 


























默认 情况 下 ， 如 果 文 档 中 存在 ”id" 字 段 ， 这 个 





字段 就 会 被 返回 〈"_id" 字 段 可 以 被 一 些 管道 操 
作 符 移 除 ， 也 可 能 已 经 被 之 前 的 投射 操作 给 移 除 
J) 。 可 以 使 用 上 面 的 代码 将 ”id" 从 结果 文档 
中 移 除 。 包 含 字段 和 排除 字段 的 规则 与 常规 查询 
中 的 语法 一 致 。 


也 可 以 将 投射 过 的 字段 进行 
将 每 个 用 户 文 档 的 "_id" 奉 
为 "userId": 
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可 结果 中 重 命名 
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> db.users.aggregate({"$project" : {"userI 
{ 


"result" : [ 
{ 
"userId" : ObjectId("50e4b3242 
}, 
{ 
"userId" : ObjectId("50e4b3252 
} 
]， 
"Ok" : 1 


























这 里 的 "$fieLdname" 语 法 是 为 了 在 聚合 框架 中 
引用 fieldname 字 段 (上 面 的 例子 中 是 "_id") 
的 值 。 例 如 ，"$age" 会 被 蔡 换 为 "age" 字 段 的 内 



































容 ( 可 能 是 数值 ， 也 可 能 是 字符 
$) ，"$tags .3" 会 被 蔡 换 为 tags 数 组 中 的 第 4 
个 元 素 。 所 以 ， 上 面 例子 中 的 "$_id" 会 被 蔡 换 为 
进入 管道 的 每 个 文档 的 " id" 字段 的 值 。 


注意 ， 必 须 明 确 指定 将 "_ id" 排除 ， 和 否则 这 个 字 
段 的 值 会 被 返 ae 一 次 被 标 为 "userId"， 

一 次 被 标 为 "_id"。 可 以 使 用 这 种 技术 生成 字段 
的 多 个 副本 ， DRE 后 的 "$group" 中 使 用 。 


在 对 字段 进行 重 命名 时 ，MongoDB 并 不 会 记录 字 
段 的 历史 名 称 。 因 此 ， 如 果 
在 "originalFieldname" 字 段 上 有 一 个 索引 ， 
聚合 框架 无 法 在 下 面 的 排序 操作 中 使 用 这 个 索 
引 ， 尽 管 人 眼 一 下 子 就 能 看 出 下 面 代码 中 
HJ"newFieldname"5"originalFieldname"# 
示 同 一 个 字段 。 



























































































































































> db.articles.aggregate({"$project" : {"ne 
. {"$sort" : {"newFieldname" : 1}}) 


























所 以 ， 应 该 尽量 在 修改 字段 名 称 之 前 使 用 索引 。 
1. 管道 表达 式 
最 简单 的 "$project" 表 达 式 是 包含 和 排除 字 























Cexpression) 将 多 个 


中 使 用 。 




















iy teat baa ADEME E 



























































面 量 和 变量 组 合 在 一 个 值 























在 聚合 框架 中 有 几 个 表达 式 可 用 来 组 合 或 者 进行 




















任意 深度 的 嵌 套 ， 以 便 创 建 复杂 的 表达 式 。 


2. 数学 表达 式 (mathematical 


expression ) 




















算术 表达 式 可 用 于 操作 数值 。 指 定 一 组 数值 ， 就 
可 以 使 用 这 个 表达 式 进行 操作 了 。 例 如 ， 下 面 的 









































表达 式 会 将 "salary" 和 "bonus" 字 段 的 值 相 加 。 





} 
eek } 
. }) 





"$project" 
"totalPay" : { 
"$add" : ["$salary", "$bo 





> db.employees.aggregate( 


: { 


可 以 将 多 个 表达 式 嵌 套 在 一 起 组 成 更 复杂 的 表达 


式 。 假 设 我 们 想 要 从 总 





金额 中 扣除 为 401(k) P 




















缴纳 的 金额 。 可 以 使 用 "$subtract "表达 式 : 


1 401(9 是 美国 的 一 种 养老 金 计划 。 一 一 译 者 注 





























> db.employees.aggregate( 


"$project" : { 
"totalPay" : { 
"$subtract" : [{"$add" : 
} 


ee } 
. }) 


























RE 达 式 可 以 进行 任意 层次 的 府 套 。 


下 面 是 每 个 操作 符 的 语法 : 











"$add" : [expr1[, expr2, ..., exprN]] 
这 个 操作 符 接受 一 个 或 多 个 表达 式 作 为 参数 ， 将 
这 些 表达 式 相 加 。 








"$subtract" : [expr1, expr2] 
接受 两 个 表达 式 作 为 参数 ， 用 第 一 个 表达 式 减 去 
第 二 个 表达 式 作 为 结 





























"$€multiply" : [expri[, expr2, ..., 
exprNn] ] 
接受 一 个 或 者 多 个 表达 式 ， 并 且 将 它们 相 乘 。 


"$divide" : [expri1, expr2] 
接受 两 个 表达 式 ， 用 第 一 个 表达 式 除 以 第 二 个 表 
达 式 的 商 作为 结果 。 









































"$mod" : [expr1, expr2] 
接受 两 个 表达 式 ， 将 第 一 个 表达 式 除 以 第 二 个 表 
达 式 得 到 的 余数 作为 结果 。 





























3. 日 期 表达 式 (date expression ) 


许多 聚合 都 是 基于 时 间 的 : 上 周 发 生 了 什么 ? 上 
ea 年 间 发 生 了 什么 ? 因 
， 聚 合 框 染 中 包含 了 一 些 用 于 提取 日 期 信息 的 



























































in "$year". “$month”, "$Sweek". "$dayOFM 
只 能 对 日 期 类 型 的 字段 进行 日 期 操作 ， 不 能 对 数 
值 类 型 字段 做 日 期 操作 。 
每 种 日 期 类 型 的 操作 都 是 类 似 的 : 接受 一 个 日 期 

式 ， 返 回 一 个 数值 。 下 面 的 代码 会 返回 每 个 
入 职 的 月 份 : 


> db.employees.aggregate( 
era 








































































































"$project" 
"hiredIn" : {"$month" : "$hire 


ane } 
. }) 















































也 可 以 使 用 期 。 下 面 的 代码 会 计算 
个 雇员 在 公司 内 的 工作 有 时间， 

















a 

















> db.employees.aggregate( 
"$project" : { 
"tenure" 
"$subtract" : [{"$year" 
} 


} 





DE 








4. 字符 串 表 达 式 (string expression ) 
































也 有 一 些 基本 的 字符 串 操 作 可 以 使 用 ， 它 们 的 签 
名 如 下 所 示 : 





"$substr" : [expr, startOffset, 
numToReturn] 

中 第 一 个 参数 expr 必 须 是 个 字符 串 ， 这 个 操作 
会 截取 这 个 字符 串 的 子 串 (从 第 startoffset 字 
节 开 始 的 numToReturn 字 节 ， 注 意 ， 是 字 节 ， 不 
是 字符 。 在 多 字 节 编码 中 尤其 要 注意 这 一 

点 ) expr 必 须 是 字符 串 。 







































































"$concat" : [exprif, expr2, ..., 
exprN]] 

将 给 定 的 表达 式 〈 或 者 字符 串 ) 连接 在 一 起 作为 
返回 结果 。 























"¢toLower" : expr 
参数 expr 必 须 是 个 字符 串 值 ， 这 个 操作 返 
expr 的 小 写 形式 。 




















"$toUpper" : expr 





ua 





参数 expr 必 须 是 个 字符 串 值 ， 这 个 操作 返 
expr 的 大 写 形式 。 


改变 字符 大 小 写 的 操作 ， 只 保证 对 罗马 字符 有 
效 。 


下 面 是 一 个 生成 j.doe@example.com 格 式 的 email 
地 址 的 例子 。 它 提取 "$firstname" 的 第 一 个 字 
符 ， 将 其 与 多 个 常量 字符 串 和 "$1lastname "连接 
成 一 个 字符 串 : 


















































> db.employees.aggregate( 


"$project" : { 
"email" : { 
"$concat" : [ 


{"$substr" : ["$firstNn 


> 3 
"$lastName", 
"@example.com" 


} 





x 





5. 逻辑 表达 式 (Jogical expression ) 
有 一 些 逻 辑 表 达 式 可 以 用 于 控制 语句 。 
下 面 是 几 个 比较 表达 式 。 











"$cmp" : [expr1, expr2] 

比较 expr1 和 expr2。 如 果 expr1 等 于 expr2， 返 
Elo; 如 果 expr1 < expr2， 返 回 一 个 负数 ;如 果 
expr1 >expr2， 返 回 一 个 正 数 。 






































"€strcasecmp" : [string1, string2] 
比较 string1 和 string2， 区 分 大 小 写 。 只 对 罗 
马 字符 组 成 的 字符 串 有 效 。 


"$eq"/"$ne"/"$gt"/"$gte"/"$1t"/"$1te" 
: [expr1, expr2] 


对 expr1 和 expr2 执 行 相 应 的 比较 操作 ， 返 回 比 




















较 的 结果 (true 或 false) 。 
下 面 是 儿 个 布尔 表达 式 。 

"$and" : [expr1i[, expr2, ..., exprN]] 
如 果 所 有 表达 式 的 值 都 是 true， 那 就 返 下 


true， 奉 则 返回 false。 















































"gor" : [expri[, expr2, ..., exprN]] 
只 要 有 任意 表达 式 的 值 为 true， 就 返回 true， 
否则 返回 false。 




















"$not" : expr 


对 expr 取 反 。 
还 有 两 个 控制 语句 。 





"$cond" : [booleanExpr, trueExpr, 
falseExpr] 

如 果 booLeanExpr 的 值 是 true， 那 就 返 匠 
trueExpr, TURE falseExpr. 





























"$ifNull" : [expr, replacementExpr | 
如 果 expr 是 null1， 返 回 repLacementExpr， 
则 返回 expr。 


通过 这 些 操作 符 ， 就 可 以 在 聚合 中 使 用 更 复杂 的 


























oy 
























































逻辑 ， 可 以 对 不 同 数据 执行 不 同 的 代码 ， 得 到 不 


同 的 结果 。 


管道 对 于 输入 数据 的 形式 有 特定 要 求 ， 所 以 这 些 
操作 符 在 传 入 数据 时 要 特别 注意 。 算 术 操 作 符 必 




















须 接受 数值 ， 日 期 操作 符 必须 接受 日 期 ， 字 符 






































通过 这 个 条 件 来 检测 缺失 的 值 ， 并 且 进 行 填充 。 
6. 一 个 提取 的 例子 





























假如 有 个 教授 想 通过 某 种 比较 复杂 的 计算 为 学 生 
打分 : 出 勤 率 占 10%， 日 常 测验 成 绩 占 30%， 期 

















操作 符 必 须 接受 字符 串 ， 如 果 有 字符 缺失 ， 这 些 
操作 符 就 会 报错 。 如 果 你 的 数据 集 不 一 致 ， 可 以 





末 考 试 占 60% (如 果 是 老师 最 宠爱 的 学 生 ， 那 么 





分 数 就 是 100) 。 可 以 使 用 如 下 代码 : 








> db.students.aggregate( 
-{ 
"$project" : { 
"grade" : { 
"$cond" : [ 
"¢$teachersPet", 
100, // if 
{ // else 
"$add" : [ 
{"$multiply" 








{"$multiply" 
{"$multiply" 


} 
} 








03) 


7.2.3 $group 





$group 操 作 可 以 将 文档 依据 特定 字段 的 不 同 值 进 
行 分 组 。 下 面 是 几 个 分 组 的 例子 。 

。 如 果 我 们 以 分 钟 作为 计量 单位 ， 希 望 找 出 
天 的 平均 湿度 ， 就 可 以 根据 "day" 字 段 进行 


。 如果 有 一 个 学 生 集 合 ， 希 望 按照 分 数 等 级 将 
学 生 分 为 多 个 组 ， 可 以 根据 "grade" 字 段 进 




















et 






































。 如 果 有 一 个 用 户 集合 ， 和 希望 知道 每 个 城市 有 
多 少 用 户 ， 可 以 根据 "state" 和 "city" 两 个 
字段 对 集 合 进 行 分 组 ， 每 
个 "city"/"state" 对 对 应 一 个 分 组 。 不 应 
该 只 根据 "city" 字 段 进行 分 组 ， 因 为 不 同 的 
州 可 能 拥有 相同 名 字 的 城市 。 




























































































如 果 选 定 了 需要 进行 分 组 的 字段 ， 就 可 以 将 选 定 
的 字段 传递 给 "$group" 函 数 的 "_id" 字 段 。 对 于 
上 面 的 例子 ， 相 应 的 代码 如 下 : 


e {"$group" : {"_id" : "$day"}} 

e {"$group" : {"_id" : "$grade"}} 

e {"$group" : {"_id" : {"state" 
"$state", "city" : "$city"}}} 


如 果 执行 这 些 代 码 ， 结 果 集 中 每 个 分 组 对 应 一 个 
只 有 一 个 字段 〈 分 组 键 ) 的 文档 。 例 如 ， 按 学 4 
ee cy Vita Hy A 能 是 : {"result" 

[{"_ > “At"}, {"_id ae ee 
$ re oy, tea tee de EP] 
1}。 Wd Lees, TUGAR es Bebe 
一 个 不 同 的 值 ， 但 是 所 有 例子 都 要 求 基于 这 些 分 
组 进行 一 些 计 算 。 因 此 ， 可 以 添加 一 些 字段 ， 使 
分 组 操作 符 对 每 个 分 组 中 的 文档 做 一 些 计算 。 


1. 分 组 操作 符 


这 些 分 组 操作 符 允 许 对 每 个 分 组 进行 计算 ， 得 到 
相应 的 结果 。7.1 节 介绍 过 "$sum" 分 组 操作 符 的 
EH: 分 组 中 每 出 现 一 个 文档 ， 它 就 对 计算 结果 
加 1， 这 样 便 可 以 得 到 每 个 分 组 中 的 文档 数量 。 
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2. 算术 操作 符 


有 两 个 操作 符 可 以 用 于 对 数值 类 型 字段 的 值 进行 
计算 : "$sum" 和 "$average"。 









































e "$sum" : value 
ea eee ee 
结果 相 加 。 注 意 ， 上 面 的 例子 中 使 用 了 一 个 
字面 量 数字 1， 但 是 这 里 也 可 以 使 用 比较 复 
杂 的 值 。 例 如 ， 如 果 有 一 个 集合 ， 其 中 的 内 
容 是 各 个 国家 的 销售 数据 ， 使 用 下 面 的 代码 




































































































































































就 可 以 得 到 每 个 国家 的 总 收入 : 
> db.sales.aggregate( 
"$group" : { 

”id”: "$country", 
"totalRevenue" : {"$sum" 

eee } 

-H 
e "$avg" : value 


返回 每 个 分 组 的 平均 值 。 
例如 ， 下 面 的 代码 会 返回 每 个 国家 的 平均 收 
入 ， 以 及 每 个 国家 的 销量 : 



































> db.sales.aggregate( 








1} 


.{ 
s "$group" : { 
"_ id" : "$country", 
"totalRevenue" : {"$avg" 
"numSales" : {"$sum" 
one } 
-H 








3. 极 值 操作 符 (extreme operator ) 



































下 面 的 四 个 操作 符 可 用 于 得 到 数据 集合 中 的 “ 边 









































缘 ” 值 。 
e "$max" : expr 返回 分 组 内 的 最 大 值 。 
e "$min" : expr 
回 分 组 内 的 最 小 值 。 




















e "$first" : expr 返回 分 组 的 第 一 个 值 














忽略 后 面 所 有 值 。 只 有 排序 之 后 ， 明 确 知 道 























数据 顺序 时 这 个 操作 才 有 意义 。 





"$last" : expr 


'$first" 相 反 ， 返 回 分 组 的 最 后 一 个 





值 。 


























"$max" 和 "$min" 会 查看 每 一 个 文档 ， 以 便条 









































极 值 。 因 此 ， 如 果 数 据 是 无 序 的 ， 这 两 个 操作 符 
也 可 以 有 效 工作 ;如果 数 据 是 有 序 的 ， 这 两 个 操 

ee ee 假设 有 一 个 存 有 学 生 考 试 成 
绩 的 数据 集 ， 需 要 找到 其 中 的 最 高 分 与 最 低 分 : 
































































































































> db.scores.aggregate( 
{ 
; "$group" : { 
é ""id" : "$grade", 
: "lowestScore" : {"$min" "$sc 
; "highestScore" : {"$max" : "$s 
. } 
. }) 
另 一 方面 ， 如 果 数 据 集 是 按照 希望 的 字段 排序 过 
的 ， 那 么 "$first" 和 "$1ast" 操 作 符 就 会 非常 有 
]。 下 面 的 代码 与 上 面 的 代码 可 以 得 到 同样 的 结 
R: 
> db.scores.aggregate( 
sas "$sort" : {"score" : 1} 
Pee ES 
-{ 
"$group" : { 
"id" : "$grade", 
“lowestScore" : {"$first" : "$ 
"highestScore" : {"$last" : "$ 





ee } 
. }) 

















如 果 数 据 是 排 过 序 的 ， 那 么 $first 和 $1last 会 比 
$min 和 $max 效 率 更 高 。 如 果 不 准 备 对 数据 进行 
排序 ， 那 么 直接 使 用 $min 和 $max 会 比 先 排 序 再 
使 用 $first 和 $1ast 效 率 更 高 。 


4. 数组 操作 符 
有 两 个 操作 符 可 以 进行 数组 操作 。 




































































e "$addToSet" : expr 
如 果 当 前 数组 中 不 包含 expr ， 那 就 将 它 添 


加 到 数组 中 。 在 返回 结果 集中 ， 每 个 元 素 最 
多 只 出 现 一 次 ， 而 且 元 素 的 顺序 是 不 确定 
的 。 












































e "$push" : expr 
不 管 expr 是 什么 值 ， 都 将 它 添 加 到 数组 中 。 
返回 包含 所 有 值 的 数组 。 


























有 两 个 操作 符 不 能 用 前 面 介 绍 的 流 式 工作 方式 对 
文档 进行 处 理 ，"$group" 是 其 中 之 一 。 大 部 分 


















































操作 符 的 工作 方式 都 是 流 
入 ， 就 可 以 对 新 文档 进行 处 理 ， 但 
是 是 "$group" 必 须要 等 收 到 所 有 的 
， 然 后 才能 将 各 

道中 的 下 一 个 操作 符 。 这 意味 着 
况 下 ， "$group "会 先 在 每 个 分 片 











能 对 文档 进行 人 分 组 





各 个 分 片上 的 分 组 乡 


式 的 ， 只 
























































上 执行 ， 然 后 

















只 要 有 新 文档 进 











文档 之 后 ， 才 


个 分 组 发 送 给 
， 在 分 片 的 情 




















结果 会 被 发 送 到 mongos 再 进行 


最 后 的 统一 分 组 ， 剩 余 的 管道 工作 














mongos 《而 不 是 在 分 





tr) 

















也 都 是 在 








上 运行 的 。 





7.2.4 Sunwind 





























拆 分 Cunwind) 可 以 将 数组 中 的 每 








一 个 值 拆 分 为 

















单独 的 文档 。 例 如 ， 如 果 有 一 篇 拥 





























有 多 条 评论 的 
每 条 评论 拆 分 为 











寺 客 文章 ， 可 以 使 用 $unwind 将 
一 个 独立 的 文档 : 
> db.blog.findone() 
{ 
" "id" : ObjectId("50eeffc4c82a52712905 
"author" "K", 
"post" : "Hello, world!", 
"comments" : [ 
{ 
"author" "mark", 
"date" 
"text" "Nice post" 





: ISODate("2013-01-10T1 








{ 
"author" : "bill", 
"date" : ISODate("2013-01-10T1 
"text" : "I agree" 
} 
] 
} 
> db. blog.aggregate({"$unwind" : "$comment 
{ 
"results" 
{ 
”id”: ObjectId("50eeffc4c82a 
"author" : "k", 
"post" : "Hello, world!", 
"comments" : { 
"author" : "mark", 
"date" : ISODate("2013-01- 
"text" : "Nice post" 
} 
}s 
{ 
”id”: ObjectId("50eeffc4c82a 
"author" : "k", 
"post" : "Hello, world!", 
"comments" : { 
"author" : "bill", 


"date" : ISODate("2013-01- 
"text" : "I agree" 
































如 果 希 望 在 查询 中 得 到 特定 的 子 文档 ， 这 个 操作 
符 就 会 非常 有 用 : 先 使 用 "$unwind" 得 到 所 有 子 
文档 ， 再 使 用 "$match" 得 到 想 要 的 文档 。 例 
如 ， 如 果 要 得 到 特定 用 户 的 所 有 评论 〈 只 需要 条 
到 评论 ， 不 需要 返回 评论 所 属 的 文章 ) ， 使 用 普 
通 的 查询 是 不 可 能 做 到 的 。 但 是 ， 通 过 提取 、 拆 
分 、 匹 配 ， 就 很 容易 了 : 





































































































































































































> db.blog.aggregate({"$project" : {"commen 
. {"$unwind" : "$comments"}, 
. {"$match" : {"comments.author" : "Mark 
































由 于 最 后 得 到 的 结果 仍然 是 一 个 "comments" 子 
文档 ， 所 以 你 可 能 希望 再 做 一 次 投射 ， 以 便 让 输 
出 结果 更 优雅 o 
























































7.2.5 $sort 


可 以 根据 任何 字段 〈 或 者 多 个 字段 ) 进行 排序 ， 
与 在 普通 查询 中 的 语法 相同 。 如 果 要 对 大 量 的 文 



















































































档 进 行 排序 ， 强 烈 建议 在 管道 的 第 一 阶段 进行 排 
序 ， 这 时 的 排序 操作 可 以 使 用 索引 。 和 否则 ， 排 序 
过 程 就 会 比较 慢 ， 而 且 会 占用 大 量 内 存 。 


可 以 在 排序 中 使 用 文档 中 实际 存在 的 字段 ， 也 可 
以 使 用 在 投射 时 重 命名 的 字段 





































































































> db.employees.aggregate( 
weir of 
. "$project" : { 
; "compensation" : { 
F "$add" : ["$salary", "$bon 
$ "name" : 1 
. } 
eh 
.{ 
ae "$sort" : {"compensation" : -1, "n 
. 3) 





这 个 例子 会 对 员工 排序 ， 最 终 的 结果 是 按照 报酬 
从 高 到 低 ， 姓 名 从 A 到 Zz 的 顺序 排列 。 


排序 方向 可 以 是 1 (升序 ) 和 -1 (降序 ) 。 


与 前 面 讲 过 的 "$group" 一 样 ，"$sort "也 是 一 个 
无 法 使 用 流 式 工 作 方式 的 操作 符 。"$sort" 也 必 
























































须要 接收 到 所 有 文档 之 后 才能 进行 排序 。 在 分 片 
环境 下 ， 先 在 各 个 分 片上 进行 排序 ， 然 后 将 各 个 
分 片 的 排序 结果 发 送 到 mongos 做 进一步 处 理 。 






























































7.2.0 Şlimit 





























的 前 2 个 








$1imit 会 接受 一 个 数字 n， 返 回 结果 外 
文档 。 





ay 








7.2.7 $skip 

















$skipth ÆSA En, BFARE pAn 
个 文档 ， 将 剩余 文档 作为 结果 返回 。 在 “普通 * 查 
询 中 ， 如 果 需 要 跳 过 大 量 的 数据 ， 那 么 这 个 操作 
符 的 效率 会 很 低 。 在 聚合 中 也 是 如 此 ， 因 为 它 必 
须要 先 匹 配 到 所 有 需要 跳 过 的 文 要 ， 然 后 再 将 这 
些 文档 丢弃 。 








































































































再 


7.2.8 ”使 用 管道 





应 该 尽量 在 管道 的 开始 阶段 〈 执 
行 "$project"、"$group" 或 者 "$unwind" 操 作 
之 前 ) 就 将 尽 可 能 多 的 文档 和 字段 过 滤 掉 。 管 道 
如 果 不 是 直接 从 原先 的 集合 中 使 用 数据 ， 那 就 无 
法 在 算 选 和 排序 中 使 用 索引 。 如 果 可 能 ， 聚 合 管 


































































































道 会 尝试 对 操作 进行 排序 ， 以 便 
| 


MongoDB 不 允许 单一 的 聚合 操作 占 
内 存 : 如 果 MongoDB 发 现 某 个 聚合 操作 占用 了 










































































20% 以 上 的 内 存 ， 











这 个 操作 就 会 直 








允许 将 输出 结果 利用 























ne 
小 ) 




















如 果 能 够 通过 "$match" 操 作 迅 速 减 小 
大 小 ， 就 可 以 使 用 管道 进行 实时 聚合 。 











(这 样 可 以 将 所 需 



































接 输 出 错误 。 
管道 放 入 一 个 集合 中 是 为 了 
的 内 存 减 至 最 


BREN 


能 够 有 效 使 用 索 


过 多 的 系统 























于 管道 


会 不 断 包含 更 多 的 文档 ， 会 越 来 越 复 杂 ， 所 以 几 





乎 不 可 能 实时 得 到 管道 的 操作 结果 。 


7.3 MapReduce 





A Bx 














中 的 明星 ， 








MapReduce 均 聚合 工 
非常 灵活 。 
架 的 查询 语言 来 表达 ， 
Mop S ia o 


有 些 问题 过 于 复杂 ， 无 法 使 / 
这 时 可 以 使 用 


MapReduce 使 用 JavaScript 作 为 “查询 



































它 非常 强大 、 





聚合 

































































语言 


而 ， 
不 应 该 
































MapReduce 能 

















”， 因 此 它 能 够 表达 任意 复杂 的 逻辑 。 然 
这 种 强大 是 有 代价 的 MapReduce 非 常 慢 ， 
在 实时 的 数据 分 析 中 。 


够 在 多 台 服 务 器 之 间 并 行 执行 。 它 








E 


会 将 一 个 大 问题 分 割 为 多 个 小 问题 ， 将 各 个 小 问 
题 发送 到 不 同 的 机 器 上 ， 每 台 机 器 只 负责 完成 
部 分 工作 。 所 有 机 器 都 完成 时 ， 再 将 这 些 零碎 的 
解决 方案 合并 为 一 个 完整 的 解决 方案 。 


MapReduce 需 要 几 个 步骤 。 最 开始 是 映射 
(map) ， ee 这 
个 操作 要 么 “无 作为 ”， 要 么 “产生 一 些 键 和 X 个 
值 ”。 然 后 就 是 : 各 环节 ， pan (shuffle) ， 
按照 键 分 组 ， 并 将 产生 的 键 值 组 成 列表 放 到 对 应 
的 键 中 。 化 简 (reduce〉 则 把 列表 中 的 值 化 简 成 












































z 























一 个 单 值 。 这 个 值 被 返回 ， 然 后 接着 进行 洗 牌 
直到 每 个 键 的 列表 只 有 一 个 值 为 止 ， 这 个 值 也 就 
是 最 终结 果 。 


下 面 会 多 举 几 个 MapReduce 的 例子 ， 这 个 工具 非 
常 强大 ， 但 也 有 点 复杂 



































a ~ 

























































































7.3.1 示例 1: 找 出 集合 中 的 所 有 键 

















MapReduce 来 解决 这 个 问题 有 点 大 材 小 用 ， 不 
过 还 是 一 种 了 解 其 机 制 的 不 错 的 方式 。 要 是 已 经 
知道 MapReduce 的 原理 ， 则 直接 跳 到 本 节 最 后 ， 
看 看 MongoDB 中 MapReduce 的 使 用 注意 事项 。 


MongoDB 会 假设 你 的 模式 是 动态 的 ， 所 以 并 不 跟 

































































踪 记 录 每 个 文档 中 的 键 。 通 常 找 到 集合 中 所 有 文 
档 所 有 键 的 最 好 方式 就 是 用 MapReduce。 在 本 例 
中 ， 会 记录 每 个 刍 出 现 了 多 少 次 。 内 内 文档 中 的 
键 就 不 计算 了 ， 但 给 map 函 数 做 个 简单 修改 就 能 
实现 这 个 功能 


在 映射 环节 ， 我 们 希望 得 到 集合 中 每 个 文档 的 所 
有 键 。map 函 数 使 用 特别 的 emit 函 数 “ 返 回 ” 要 处 
理 的 值 。emit 会 给 MapReduce 一 个 键 〈( 类 似 于 前 
面 $group 所 使 用 的 键 ) 和 一 个 值 。 这 里 用 emit 
将 文档 某 个 键 的 计数 (count) 返回 count : 
1}) 。 我 们 想 为 每 个 键 单独 计数 ， 所 以 为 文档 中 
的 每 个 键 调 | 一 次 emit。this 就 是 当前 映射 文 
档 的 引用 


> map = function() { 
. for (var key in this) { 

fe emit(key, {count : 1}); 
meee 


这 样 就 有 了 许 许 多 多 {count : 1} 文 档 ， 每 一 个 
都 与 集合 中 的 一 个 键 相关 。 这 种 由 一 个 或 多 个 

{count : 1} 文 档 组 成 的 数组 ， 会 传递 给 reduce 
函数 。reduce 函 数 有 两 个 参数 ， 一 个 是 key， 也 
就 是 emit 返 回 的 第 一 个 值 ， 还 有 另外 一 个 数组 ， 
由 一 个 或 者 多 个 与 键 对 应 的 {count : 1} 文 档 组 






















































































































































































































































































成 。 


> reduce = function(key, emits) { 
. total = 
. for (var i in emits) { 
total += emits[i].count; 





. return {"count" : total}; 


- I 


reduce 一 定 要 能 够 在 之 前 的 map 阶 段 或 者 前 一 
个 reduce 阶 段 的 结果 上 反复 执行 。 所 以 reduce 
返回 的 文档 必须 能 作为 reduce 的 第 二 个 参数 的 一 
个 元 素 。 例 如 ，x 键 映射 到 了 3 个 文档 {count : 
1, id : 1}, {count : 1, id : 2} 和 {count 
: 1, id : 3}， 其 中 id 键 只 用 于 区 分 不 同 的 文 






























































4 




















档 。MongoDB 可 能 会 这 样 调用 reduce: 








> r1 = reduce("x", [{count : 1, id : 1}, { 





{count : 2} 

> r2 = reduce("x", [{count : 1, id : 3}]) 
{count : 1} 

> reduce("x", [r1, r2]) 

{count : 3} 








不 能 认为 第 二 个 参数 总 是 初始 文档 之 一 《比如 
{count:1}) 或 者 长 度 固定 。reduce 应 该 能 处 









































Ars! 














里 emit 文 档 和 其 他 reduce 返 回 结果 的 各 种 组 








o 


总 之 ，MapReduce 函 数 可 能 会 是 下 面 这 样 : 


TT 








> mr = db.runCommand({"mapreduce" : "foo", 
{ 
"result" : "tmp.mr.mapreduce_126678781 
"timeMillis" : 12, 
"counts" : { 
"input" : 6 
"emit" : 14 
"output" : 5 
3 
"ok" : true 
} 


























MapReduce 返 回 的 文档 包含 很 多 与 操作 有 关 的 元 
信息 。 

















e "result" 

"tmp.mr.mapreduce_ 1266787811 _ 1" 
这 是 存放 MapReduce 结 果 的 集合 名 。 这 是 个 
临时 集合 ，MapReduce 的 连接 关闭 后 它 就 被 
自动 删除 了 。 本 章 稍 后 会 介绍 如 何 指定 一 个 






































zh} 


好 一 点 的 名 字 以 及 将 结果 集合 持久 化 。 





co 








e "timeMillis" : 12 





操作 花 缆 的 时 间 ， 单 位 是 毫秒 。 


e "counts" : {. } 












































































































































这 个 内 内 文档 主要 用 作 调试 ， 其 中 包含 3 个 
键 。 
o "input" : 6 
发 送 到 map 函 数 的 文档 个 数 。 
o "emit" : 14 
在 map 函 数 中 emit 被 调用 的 次 数 。 
o "output" : 5 
结果 集合 中 的 文档 数量 。 
对 结果 集合 进行 查询 会 发 现 原 有 集合 的 所 有 键 及 
其 计数 : 
> img result]. find() 
{' : "id", "value" : te ‘count" : 6 } 
{' "a", "value" : { "count" : 4 } } 
{' "b", "value" : { "count" : 2 } } 
{' "x", "value" : { "count" : 1 } } 
: "y", "value" : { "count" : 1 } } 

















这 个 结果 集中 的 每 个 "_id" 对 应 原 集合 











的 一 个 








键 ，"value" 键 的 值 就 是 reduce 的 最 终结 果 。 


7.3.2 示例 2: 网 页 分 类 





假设 有 个 网 站 ， 人 们 可 以 提交 其 他 网 页 的 链接 ， 
比如 reddit (http://www.reddit.com) 。 提 交 者 可 
以 给 这 个 链 接 添 加 标签 ， 表明 主题 ， 比如 
politics、 geek 或 者 icanhascheezburger。 可 以 用 
MapReduce 找 出 哪个 主题 最 为 热门 ， 热 门 与 否 由 
最 近 的 投票 决定 。 


， 建 立 一 个 map 函 数 ， 发 出 〈emit) 标签 和 一 
于 流行 度 和 新 旧 程度 的 值 。 


map = function() { 
for (var i in this.tags) { 
var recency = 1/(new Date() - this 
var score = recency * this.score; 





















































nt oF 


a 








emit(this.tags[i], {"urls" : [this 
} 
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现在 就 化 简 同一 个 标签 的 所 有 值 ， 以 得 到 这 个 标 
签 的 分 数 : 


|reduce = function(key, emits) { 




















var total = {urls : [], score : ©} 


for (var i in emits) { 
emits[i].urls.forEach(function(url 


total.urls.push(ur1) ; 
} 


total.score += emits[i].score; 


return total; 





}3 








ee a 
签 流行 程度 的 分 数 。 


a 





7.3.3 MongoDB# MapReduce 














前 面 两 个 例子 只 用 到 了 mapreduce、map 和 
peace 这 3 个 键 是 必需 的 ， 但 是 MapReduce 
命令 还 有 很 多 可 选 的 键 。 














e "finalize" : function 
可 以 将 reduce 的 结果 发 送 给 这 个 键 ， 这 是 整 
个 处 理 过 程 的 最 后 一 步 。 




















"keeptemp" : boolean 
如 果 为 值 为 true， 那 么 在 连接 关闭 时 会 将 临 
时 结果 集合 保存 下 来 ， 否 则 不 保存 。 





























e "out" : string 
输出 集合 的 名 称 。 如 果 设 置 了 这 选项 ， 系 统 


会 自动 设置 Keeptemp : true。 




































































e "query" : document 
在 发 往 map 函 数 前 ， 先 用 指定 条 件 过 滤 文 
档 

e "sort" : document 











在 发 往 map 前 先 给 文档 排序 〈 与 1imit 一 同 
使 用 非常 有 用 ) 。 
































e "limit" : integer 


发 入 map 函数 的 文档 数量 的 上 限 。 





e "scope" : document 


可 以 在 JavaScript 代 码 中 使 用 的 变量 。 



































e "verbose" : boolean 


是 否 记录 详细 的 服务 器 日 志 。 











1. finalize% žk 


和 group 命 令 一 样 ，MapReduce 也 可 以 使 
jfinalize 函 数 作为 参数 。 它 会 在 最 后 一 
个 reduce 输 出 结果 后 执行 ， 然 后 将 结果 存 到 临时 





























集合 中 。 


返回 体积 比较 大 的 结果 集 对 MapReduce 不 是 什么 
大 不 了 的 事情 ， 因 为 它 不 像 group 那 样 有 4 MB 的 
限制 。 然 而 ， 信 息 总 是 要 传递 出 去 的 ， 通 常 来 
说 ，finalize 是 计算 平均 数 、 裁 前 数组 、 清 除 
多 余 信息 的 好 时 机 。 


2. 保存 结果 集合 


默认 情况 下 ，Mongo 会 在 执行 MapReduce 时 创建 
一 个 临时 集合 ， 集 合 名 是 系统 选 的 一 个 不 太 常 用 
的 名 字 ， 将 "mr"、 执 行 MapReduce 的 集合 名 、 时 
间 恰 以 及 数据 库 作 业 ID， 用 “.” 连 成 一 个 字符 串 ， 
这 就 是 临时 集合 的 名 字 。 结 果 产 生 形 如 
mr.stuff. 18234210220.2 这 样 的 名 字 。MongoDB 会 
在 调用 的 连接 关闭 时 自动 销毁 这 个 集合 (也 可 以 
在 用 完 之 后 手动 删除 ) 。 如 果 和 希望 保存 这 个 集 
合 ， 就 要 将 keeptemp 选 项 指定 为 true。 


如 果 要 经 常 使 用 这 个 临时 集合 ， 你 可 能 想 给 它 起 
个 好 点 的 名 字 。 利 用 out 选 项 〈 该 选项 接受 字符 
串 作 为 参数 ) 就 可 以 为 临时 集合 指定 一 个 易 读 易 
懂 的 名 字 。 如 果 用 了 out 选 项 ， 就 不 必 指 定 

keeptemp : true 了 ， 因 为 指定 out 选 项 时 系统 
会 将 keeptemp 设 置 为 true。 即 便 你 取 了 一 个 非 





ua 































































































































































































































































































常 好 的 名 字 ，MongoDB 也 会 在 MapReduce 的 中 间 
过 程 使 用 自动 生成 的 集合 名 。 处 理 完成 后 ， 
动 将 临时 集合 的 名 字 更 改 为 你 指定 的 集合 名 ， 



































个 重 命 名 的 过 程 是 
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原子 性 的 。 也 就 是 说 ， 如 时 











次 对 同一 个 集合 调用 MapReduce， 也 不 会 在 操作 























这 个 集合 上 执 





中 遇 到 集合 不 完整 的 情况 。 


MapReduce 产 生 的 集合 就 是 一 个 普通 的 集合 ， 在 
本 MapReduce 完 全 没有 问题 ， 或 者 


























在 前 一 个 MapReduce 的 结果 上 执行 MapReduce 也 








没有 问题 ， 如 出 











Lí} 





主 复 直 到 无 穷 都 没 问题 ! 




















3. 对 文档 子 集 执行 MapReduce 























7. 


e napa j 查 询 对 文档 进行 过 滤 就 好 








部 分 执行 MapReduce。 只 需 



































每 个 传递 给 map 函 数 的 文档 都 要 先 反 序列 化 ， 从 


BSON 对 象 转换 为 JavaScript 对 象 ， 这 个 过 程 非常 
耗 时 。 如 果 事 先知 道 只 需要 对 集合 的 一 部 分 文档 









































执行 MapReduce， 那 么 在 map 之 前 先 对 文档 进行 


过 滤 可 以 极 大 地 提 高 map 速 度 。 可 以 通 























过 " query"、"limit" 和 "sort" 等 键 对 文档 进行 


过 滤 。 





























"query" 键 的 值 是 一 个 查询 文档 。 通 常 查 询 返 回 
的 结果 会 传递 给 map 函 数 。 例 如 ， 有 一 个 做 跟踪 
分 析 的 应 用 程序 ， 现 在 我 们 需要 上 周 的 总 结 摘 
要 ， 只 要 使 用 如 下 命令 对 上 周 的 文档 执行 
MapReduce 就 好 了 : 



























































> db.runCommand({"mapreduce" : "analytics" 
"query" : {"date" : {"$gt 


sort 选 项 和 1imit 一 起 使 用 时 通常 能 够 发 挥 非常 
大 的 作用 。1imit 也 可 以 单独 使 用 ， 用 来 截取 一 
部 分 文档 发 送 给 map 函 数 。 


RE pa 000 个 页 面 的 访 
问 次 数 《〈 而 不 是 一 周 的 ) ， 就 可 以 使 
Th ina 














































































































> db.runCommand({"mapreduce" : "analytics" 
"limit" : 10000, "sort" 











query、1imit、sort 可 以 随意 组 合 ， 但 是 如 果 
不 使 用 1imit 的 话 ，sort 就 不 外 有 效 发 挥 作用 。 


4. 使 用 作用 域 


MapReduce 可 以 为 mnap、reduce、finalize 函 数 




































































都 采用 一 种 代码 类 型 。 但 多 数 语言 里 ， 可 以 指定 











传递 代码 
作用 域 。 





个 参数 。 

设置 该 选项 
数 中 就 能 
的 。 例 如 


AS 

它 有 自己 的 作用 域 键 "scope"， 如 果 想 
在 MapReduce 中 使 用 客户 端的 值 ， 贝 I 必须 使 JX 
来 























的 作用 域 。 然 而 MapReduce 会 忽略 这 

































































可 以 用 “变量 名 : 值 ”这 样 的 普通 文档 3 
T, 然后 在 map、 reduce 和 finalize 函 
使 用 了 。 作 用 域 在 这 些 函数 内 部 是 不 变 
， 上 一 节 的 例子 使 用 1/(newDate() - 


































































































this.date) 计 算 页 面 的 新 旧 程度 。 可 以 将 当前 















































日 期 作为 作用 域 的 一 部 分 传递 进去 : 
> db.runCommand({"mapreduce" : "webpages", 
"scope" : {now : new Date 











这 样 ， 在 map 函 数 中 就 能 计算 1/(now - 





this.date) 了 。 




































































5. 获得 更 多 的 输出 

还 有 个 用 于 调试 的 详细 输出 选项 。 如 果 想 看 看 
MapReduce 的 运 云 行 过 程 ， 可 以 将 "verbose" 指定 
为 true。 

也 可 以 用 print 把 map、reduce、finalize 过 程 











中 的 信息 














输出 到 服务 器 日 志 上 。 














7.4 聚合 命令 








MongoDB 为 在 集合 上 执行 基本 的 聚合 任务 提供 了 
一 些 命令 。 这 些 命令 在 聚合 框架 出 现 之 前 就 已 经 
存在 了 ， 现 在 〈 大 多 数 情况 下 ) 已 经 被 聚合 框架 
取代 。 然 而 ， 复 杂 的 group 操 作 可 能 仍然 需要 使 
jJavaScript，count 和 distinct 操 作 可 以 被 简化 
为 普通 命令 ， 不 需要 使 用 聚合 框架 。 













































































7.4.1 count 























count 是 最 简单 的 聚合 工具 ， 用 于 返回 集合 中 的 
文档 数量 : 


db.foo.count() 

















b.foo.insert({"x" : 1}) 
b.foo.count() 














不 论 集 合 有 多 大 ，count 都 会 很 快 返回 总 的 文档 








也 可 以 给 count 传 递 一 个 查询 文档 ，Mongo 会 计 
算 查 询 结果 的 数量 : 









































> db.foo.insert({"x" : 2}) 
> db.foo.count() 

2 

> db.foo.count({"x" : 1}) 
1 








对 分 页 显示 来 说 总 数 非 常 必要 : 























































































































“ 共 439 个 ， 目 前 
显示 0~10 个 ”。 但 是 ， 增 加 查询 条 件 会 使 count 变 
慢 。count 可 以 使 用 索引 ， 但 是 索引 并 没有 足够 
的 元 数据 供 count 使 用 ， 所 以 不 如 直接 使 用 查询 
来 得 快 。 
7.4.2 distinct 
distinct 用 来 找 出 给 定 键 的 所 有 不 同 值 。 使 用 
时 必须 指定 集合 和 键 。 
> db.runCommand({"distinct" "people", "k 
假设 集合 中 有 如 下 文档 : 
{"name" "Ada", "age" : 20} 
{"name" "Fred", "age" : 35} 
{"name" "Susan", "age" : 60} 
{"name" "Andy", "age" : 35} 





























如 果 对 "age" 键 使 用 distinct， 会 得 到 所 有 不 同 
IEA 





> db.runCommand({"distinct" : "people", "k 
{"values" : [20, 35, 60], "ok" : 1} 





























这 里 还 有 一 个 常见 问题 : 有 没有 办 法 获得 集合 里 
下 所 有 不 同 的 键 呢 ? MongoDB 并 没有 直接 提供 这 
样 的 功能 ， 但 是 可 以 用 MapReduce 〈 详 见 7.3 节 ) 
HT-A 



























































7.4.3 group 








使 用 group 可 以 执行 更 复杂 的 聚合 。 先 选 定 分 组 
所 依据 的 键 ， 而 后 MongoDB 就 会 将 集合 依据 选 定 
键 的 不 同 值 分 成 若干 组 。 然 后 可 以 对 每 一 个 分 组 
内 的 文档 进行 聚合 ， 得 到 一 个 结果 文档 。 


Va 



























































y 
4 S, 


如果 你 熟悉 SQL， 那 么 这 个 group 
和 SQL 中 的 GROUP BY 差不多 。 


假设 现在 有 个 跟踪 股票 价格 的 站 点 。 从 上 午 10 点 


























到 下 和 























F4 点 每 隔 几 分 钟 就 会 更 新 某 只 股票 的 价 
格 ， 并 保存 在 MongoDB 中 。 现 在 报表 程序 要 获得 





























近 30 天 的 收盘 价 。 用 group 就 可 以 轻松 办 到 。 





























股价 集合 中 包含 数 以 千 计 如 下 形式 的 文档 : 

{"day" : "2010/10/03", "time" : "10/3/2010 
{"day" : "2010/10/04", "time" : "10/4/2010 
{"day" : "2010/10/03", "time" : "10/3/2010 
{"day" : "2010/10/06", "time" : "10/6/2010 
{"day" : "2010/10/04", "time" : "10/4/2010 





中 不 要 将 金额 以 浮 点 数 的 方式 存储 ， 这 个 例子 


ba 
OS oa 




















“注意 ， 由 于 精度 的 问题 ， 实 际 使 用 




















只 是 为 了 简便 才 这 么 做 。 





























我 们 需要 的 结果 列表 中 应 该 包含 每 天 的 最 后 交易 

时 间 和 价格 ， 就 像 下 面 这 样 : 

[ 
{"time" : "10/3/2018 05:00:23 GMT-400" 
{"time" : "10/4/2010 11:28:39 GMT-400" 
{"time" : "10/6/2010 05:27:58 GMT-4e0" 


先 把 集合 按照 "day" 字 段 进行 分 组 ， 然 后 在 每 个 
分 组 中 查找 "time" 值 最 大 的 文档 ， 将 其 添加 到 结 
果 集 中 就 完成 了 。 整 个 过 程 如 下 所 示 : 


> db.runCommand({"group" : { 




































































.. "ns" : "stocks", 

. "key" : "day", 

. "initial" : {"time" : @}, 

. "$reduce" : function(doc, prev) { 


if (doc.time > prev.time) { 
prev.price = doc.price; 
prev.time = doc.time; 
cach } 
«++ HH 


把 这 个 命令 分 解 开 看 看 。 

















e "ns" : "stocks" 
间 定 要 进行 分 组 的 集合 。 

















e "key" : "day" 
指定 文档 分 组 依据 的 键 。 这 里 就 
是 "day" 键 。 所 有 "day" 值 相同 的 文档 被 分 
到 一 组 。 





























"initial" : {"time" : 6} 


每 一 组 reduce 函 数 调 用 中 的 初 
始 "time" 值 ， 会 作为 初始 文档 传递 给 后 续 过 


程 。 














每 一 组 的 所 有 成 员 都 会 使 








这 个 累加 














器 ， 所 以 它 的 任何 变化 都 可 以 


e "$reduce" 








保存 下 来 。 


: function(doc，prev) { 


} 
这 个 函数 会 在 集合 内 的 每 个 文档 上 执行 。 系 


统 会 传递 两 个 参数 : 当前 文档 














(本 组 当前 的 结果 ) 。 本 例 中 
函数 比较 当前 文档 的 时 间 和 味 
如 果 当 前 文档 的 时 间 更 晚 一 些 


的 日 期 和 价格 替换 为 当前 文档 
了 ， 每 一 组 都 有 一 个 独立 的 累 
必 担 心 不 同 日 期 的 命令 会 使 / 





A o 





在 问题 一 开始 的 描述 中 ， 就 提 到 只 






































和 累加 器 文档 
， 想 让 reduce 
加 器 的 时 间 。 

些 ， 则 将 累加 器 
HHE. Sills 
加 器 ， 所 以 不 









































同一 个 累加 





要 最 近 30 天 的 




















股价 。 然 而 ， 我 们 在 这 里 迭代 了 整 


是 要 添加 " 

















>H 











condition" 的 原因 ， 























只 对 必要 下 








的 文档 进行 处 理 。 








个 集合 。 这 就 
为 这 样 就 可 以 





> db.runCommand({"group" : { 


"ns" 


"key" 


"stocks", 
"day", 


. "initial" : {"time" : 0}, 


. "$reduce" : function(doc, prev) { 
if (doc.time > prev.time) { 
prev.price = doc.price; 
prev.time = doc.time; 
. }}, 
. "condition" : {"day" : {"$gt" : "2010/ 
eee) 











— 


H"a", ISA" condition ee cae 
的 (就 是 表达 力 不 如 "condition" 好 ) 。 


最 后 就 会 返回 一 个 包含 30 个 文档 的 数组 ， 其 实 每 
个 文档 都 是 一 个 分 组 。 每 组 都 包含 分 组 依据 的 键 
(这 里 就 是 "day"” : string) 以 及 这 组 最 终 的 
prev 值 。 如 果 有 的 文档 不 存在 指定 用 于 分 组 的 

键 ， 这 些 文 档 会 被 单独 分 为 一 组 ， 缺 失 的 键 会 使 
J"day : nul1" 这 样 的 形式 。 

在 "condition" 中 加 入 "day" : {"$exists" : 
true} 就 可 以 排除 不 包含 指定 用 于 分 组 的 键 的 文 
档 。group 命 令 同时 返回 了 用 到 的 文档 总 数 

和 "key" 的 不 同 值 数量 : 











































































































































































































> db.runCommand({"group" : {...}}) 
{ 


"day" 
"time" 


"2010/10/04", 
"Mon Oct 04 2010 


"price" : 4.27 


J 








} 












































每 组 的 "price" 都 是 显 式 设置 的 ，"time" 先 
由 初始 化 器 设置 ， 然 后 在 迭代 中 进行 更 

新 。"day" 是 默认 被 加 进去 的 ， 因 为 用 于 分 组 的 
键 会 默认 加 入 到 每 个 "retval" 内 由 文档， 。 要 
是 不 想 在 结果 集中 看 到 这 个 键 ， 可 以 用 完成 器 将 


累加 器 文档 变 为 任何 想 要 BIE, EAH 
文档 (例如 数字 或 


. 使 用 完成 器 


字符 串 












































































































































p 
































完成 器 (finalizer) 用 于 精简 从 数据 库 传 到 用 户 的 
数据 ， 这 个 步 又 非常 重要 ， 因 为 group 命 令 的 输 
可 给 用 


出 结果 需要 能 够 通过 单 次 数据 库 响应 返 






















































































户 。 为 进一步 说 明 ， 这 里 举 个 博客 的 例子 ， 其 中 
每 篇 文章 都 有 多 个 标签 (tag) 。 现 在 要 找 出 每 天 
最 热门 的 标签 。 可 以 (再 一 次 ) 按 天 分 组 ， 得 到 
每 一 个 标签 的 计数 。 就 像 下 面 这 样 : 












































> db.posts. .group({ 
.. "key" : {' 'day" : true}, 
"initial" : {"tags" : {}}, 
"$reduce" : function(doc, prev) { 
for (i in doc.tags) { 
if (doc.tags[i] in prev.tags) 
prev.tags[doc.tags[i]]++; 
} else { 
prev.tags[doc.tags[i]] = 






































es } 
. th) 

得 到 的 结果 如 下 所 示 : 

[ 
{"day" : "2010/01/12", "tags" : {"nosq 
{"day" : "2010/01/13", "tags" : {"soda 
{"day" : "2010/01/14", "tags" : {"pyth 

] 








接着 可 以 在 客户 端 找 出 "tags" 文 档 中 出 现 次 数 最 
多 的 标签 。 然 而 ， 向 客户 端 发 送 每 天 所 有 的 标签 

















a ee H 了 的 键 / 值 对 
都 被 传送 给 用 户 ， 而 我 们 需要 的 仅仅 是 一 个 字符 
HB rea sy mh" finalize" $ë 
的 原因 。 "finalize" 可 以 包含 一 个 函数 ， 在 每 
晶 结 果 传 递 到 客户 端 之 前 调用 一 次 。 可 以 使 
人 吉 果 集中 
移 除 : 


> db.runCommand({"group" : { 
... "ns" : "posts", 
. "key" : {"day" : true}, 
"initial" : {"tags" : {}}, 
"$reduce" : function(doc, prev) { 
for (i in doc.tags) { 
if (doc.tags[i] in prev.tags) 
prev.tags[doc.tags[i]]++; 
} else { 
prev.tags[doc.tags[i]] = 













































































ANS 















































J 
. "finalize" : function(prev) { 
var mostPopular = ð; 
for (i in prev.tags) { 
if (prev.tags[i] > mostPopular 
prev.tag = i 
mostPopular = prev.tags[i] 








delete prev.tags 
-HH 











现在 ， 我 们 就 得 到 了 想 要 的 信息 ， 服 务 器 返回 的 
内 容 可 能 如 下 : 




















[ 
{"day" : "2010/01/12", "tag" : "winter 
{"day" : "2010/01/13", "tag" : "soda"} 
{"day" : "2010/01/14", "tag" : "nosql" 
] 








finalize 可 以 对 传递 进来 的 参数 进行 修改 ， 也 
可 以 返回 一 个 新 值 。 


2. 将 函数 作为 键 使 用 


有 时 分 组 所 依据 的 条 件 可 能 会 非常 复杂 ， 而 不 是 
单个 键 。 比 如 要 使 用 group 计 算 每 个 类 别 有 多 少 
篇 博客 文章 (每 篇 文章 只 属于 一 个 类 别 ) 。 由 于 
不 同 作者 的 风格 不 同 ， 填 写 分 类 名 称 时 可 能 有 人 
使 用 大 写 也 有 人 使 用 小 写 。 所 以 ， 如 果 要 是 按 类 
别名 来 分 组 ， 最 后 “MongoDB” 和 “mongodb” 就 是 
两 个 完全 不 同 的 组 。 为 了 消除 这 种 大 小 写 的 影 
响 ， 就 要 定义 一 个 函数 来 决定 文档 分 组 所 依据 的 
键 。 
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定义 分 组 函数 就 要 用 到 $keyf 键 〈 注 意 不 
是 "key") ， 使 用 "$keyf "的 group 命 令 如 下 所 





HE 





























> db.posts.group({"ns" : "posts", 
. "$keyf" : function(x) { return x.categ 
"initializer" : ... }) 











有 了 "$keyf"， 就 能 依据 各 种 复杂 的 条 件 进 行 分 
组 了 。 





第 8 章 ” 应 用 程序 设计 


本 章 介 绍 如 何 设计 应 用 程序 ， 以 便 更 好 地 使 用 
MongoDB， 内 容 包括 : 


。 内 舱 数 据 和 引用 数据 之 间 的 权衡 ; 
。 优 化 技巧 ; 
。 数据 一 致 性 ; 
。 模 式 迁移 ; 
。 不 适合 使 用 MongoDB 作 为 数据 存储 的 场景 。 


81 范式 化 与 反 范 式 化 


数据 表示 的 方式 有 很 多 种 ， 其 中 最 重要 的 问题 之 
一 就 是 在 多 大 程度 上 对 数据 进行 范式 化 。 范 式 化 
(normalization) 是 将 数据 分 散 到 多 个 不 同 的 集 
合 ， 不 同 集合 之 间 可 以 相互 引用 数据 。 虽 然 很 多 
文档 可 以 引用 某 一 块 数据 ， 但 是 这 块 数据 只 存储 
在 一 个 集合 中 。 所 以 ， 如 果 要 修改 这 块 数据 ， 只 

需 修改 保存 这 块 数据 的 那 一 个 文档 就 行 了 。 但 
是 ，MongoDB 没 有 提供 连接 (join) 工具 ， 所 以 
在 不 同 集合 之 间 执 行 连接 查询 需要 进行 多 次 查 
询 。 


反 范 式 化 (denormalization) 与 范式 化 相反 : 将 















































































































































































































































每 个 文档 所 需 的 数据 都 嵌入 在 文档 内 部 。 每 个 文 
档 都 拥有 自己 的 数据 副本 ， 而 不 是 所 以 文档 共 同 
引用 同一 个 数据 副本 。 这 意味 着 ， 如 果 信 息 发 生 
了 变化 ， 那 么 所 有 相关 文档 都 需要 进行 更 新 ， 但 
是 在 执行 查询 时 ， 只 需要 一 次 查询 ， 就 可 以 得 到 
所 有 数据 。 


决定 何 时 采用 范式 化 何 时 采用 反 范 式 化 是 比较 轩 
难 的 。 范 式 化 能 够 提高 数据 写 入 速度 ， 反 范式 化 
能 够 提高 数据 读 取 速 度 。 需 要 根据 自己 应 用 程序 
的 实际 需要 仔细 权衡 。 








































































































































































































8.1.1 数据 表示 的 例子 





























段 设 要 保存 学 生 和 课程 信息 。 一 种 表示 方式 是 使 
一 个 students 集 合 ( 每 个 学 生 是 一 个 文档 ) 和 一 
个 classes 集 合 〈 每 门 课程 是 一 个 文档 ) 。 然 后 用 
第 三 个 集合 studentClasses 保 存 学 生 和 课程 之 间 的 
联系 。 


> db.studentClasses.findOne({"studentId" 
{ 
















































































"Vid" : ObjectId("512512c1d86041c7dca8 

"studentId" : ObjectId("512512a5d86041 

"classes" : 
ObjectId("512512ced86041c7dca81916 








ObjectId("512512dcd86641c7dca81917 
ObjectId("512512e6d86641c7dca81918 
ObjectId("512512f6d86641c7dca81919 


} 

















如 果 
Fis FA 


类 型 的 表 连 接 ， 
只 有 

















比较 熟悉 关系 型 





BS 
虽然 你 


BE, ， 可 能 你 之 











的 每 个 结果 文档 ! 























i 





了 一 个 学 生 和 
a" id" 列表 )。 


门 课 程 〈 而 不 是 





将 课程 放 在 数组 





个 课 














MongoDB 的 风格 ， 不 过 实 








数据 ， 


大 














腿 设 要 找到 一 个 学 入 
students 集 
studentClasses 找 到 








classes 集 合 才 能 得 到 术 


=j 


ED 





需要 向 




















不 想 在 MongoDB: 
生 信 息 和 课程 信 
取 速 度 也 没有 要 求 。 






































眼 要 的 信息 。 
服务 器 请 求 三 次 查询 。 很 可 
用 这 种 数据 组 织 方式 ， 


言 息 经 常 发 生变 化 ， 而 且 对 








际 上 通常 不 会 i 














中 ， 这 有 点 儿 
这 么 保存 
































最 后 再 查询 




















为 要 经 历 很 多 次 查询 才能 得 到 真实 信 


生 所 选 的 课程 。 需 要 先 查 找 
合 找到 学 生 信息 ， 然后 查询 
课程 "_ id", 








找 出 课 














JE 
可 能 你 并 

















tay 








如 果 将 课程 引 














] 柑 入 在 学 生 文档 中 ， 就 可 


BR 
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"_id" : ObjectId("512512a5d86041c7dca8 

"name" : "John Doe", 

"classes" : [ 
ObjectId("512512ced86041c7dca81916 
ObjectId("512512dcd86041c7dca81917 
ObjectId("512512e6d86041c7dca81918 
ObjectId("512512f6d86641c7dca81919 





} 


"classes" 字 段 是 一 个 数组 ， 其 中 保存 了 John 
Doe 需 要 上 的 课程 "id"。 需 要 找 出 这 些 课程 的 
信息 时 ， 就 可 以 使 用 这 些 " id" 查询 classes 集 
合 。 这 个 过 程 只 需要 两 次 查询 。 如 果 数 据 不 需要 
随时 访问 也 不 会 随时 发 生变 化 (“随时 ” 比 “经 

常 ” 要 求 更 高 )， 那 么 这 种 数据 组 织 方式 是 非常 
好 的 。 

如 果 需 要 进一步 优化 读 取 速度 ， 可 以 将 数据 完全 
反 范式 化 ， 将 课程 信息 作为 内 骨 文 档 保存 到 学 生 
文档 的 "classes" 字 段 中 ， 这 样 只 需要 一 次 查询 
就 可 以 得 到 学 生 的 课程 信息 了 : 


{ 




































































































































































"_id" : ObjectId("512512a5d86041c7dca8 
"name" : "John Doe", 
"classes" : [ 


"class" : "Trigonometry", 
"credits" : 3, 
"room" : "204" 
}s 
{ 
"class" : "Physics", 
"credits" : 3, 
"room" : "159" 
}s 
{ 
"class" : "Women in Literature 
"credits" : 3, 
"room" : "14b" 
} 
{ 
"class" : "AP European History 
"credits" : 4, 
"room" : "321" 
} 





} 


上 面 这 种 方式 的 优点 是 只 需要 一 次 查询 就 可 以 得 
到 学 生 的 课程 信息 ， 缺 点 是 会 占用 更 多 的 存储 空 
间 ， 而 且 数 据 同步 更 困难 。 例 如 ， 如 果 物 理学 的 
学 分 变 成 了 4 分 〈 不 再 是 3 分 ) ， 那 么 选修 了 物理 
学 课程 的 每 个 学 生 文档 都 需要 更 新 ， 而 不 只 是 更 
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Sit 





"Physics" SCH 


























































































































最 后 ， 也 可 以 混合 使 用 内 髓 数据 和 引用 数据 创 
建 一 个 子 文档 数组 用 于 保存 常用 信息 ， 需 要 查询 
更 详细 信息 时 通过 引用 找到 实际 的 文档 : 
{ 
"_id" : ObjectId("512512a5d86041c7dca8 
"name" "John Doe", 
"classes" : [ 
{ 
"id" : ObjectId("512512ced860 
"class" "Trigonometry" 
}, 
{ 
"_id" : ObjectId("512512dcd860 
"class" "Physics" 
}, 
{ 
"id" : ObjectId("512512e6d860 
"class" "Women in Literature 
}, 
{ 
"id" : ObjectId("512512fðd860 
"class" "AP European History 
} 
] 














这 种 方式 也 是 不 错 的 选择 ， 因 为 内 身 
随 着 需求 的 变化 进行 修改 : 如 

中 包含 更 多 (或 者 更 少 ) WAR, A 

(或 者 更 少 ) As BCE AOC ES 


要 考虑 的 另 一 个 重要 问题 是 ， 信 息 更 新 更 频繁 
EAE RREA? MELEE ACRE 
新 ， 那 么 范式 化 是 比较 好 的 选择 。 如 果 数 据 变化 
a a a 
值得 了 。 


网 如 ， 教 科 书 上 介绍 范式 化 的 一 个 例子 可 能 是 将 
JAN j 户 地 下 保存 在 不 同 的 集合 中 但 是 ， 人 
门 几乎 不 会 改变 住址 ， 所 以 不 应 该 为 了 这 种 概率 
极 小 的 情况 〈 某 人 改变 了 住址 ) 而 牺牲 每 一 次 查 
询 的 效率 。 在 这 种 情景 下 ， 应 该 将 地 址 内 翌 在 用 
户 文档 中 。 


如 果 诀 定 使 用 内 内 文 档 ， 更 新 文档 时 ， 需 要 设置 
一 个 定时 任务 (cronjob) , 以 确保 所 做 的 每 次 更 
新 都 成 功 更 新 了 所 有 文档 。 例 如 ， 我 们 试图 将 更 
新 扩散 到 多 个 文档 ， 在 更 新 完 所 有 文档 之 前 ， 服 
务 器 骨 演 了 。 需 要 能 够 检测 到 这 种 问题 ,并且 重 
新 进行 未 完 的 更 新 。 


一 般 来 说 ， 数 据 生成 越 频繁 ， 就 越 不 应 该 将 这 些 
























































































































































































































































































































































数据 内 典 到 其 他 文档 中 。 如 果 内 和 嵌 字 段 或 者 内 嵌 
字段 数量 是 无 限 增长 的 ， 那 么 应 该 将 这 些 内 容 保 


存在 单独 的 集合 











而 不 是 内 和 能 到 其 他 文档 中 。 评 论 列表 或 者 活动 列 

















， 使 用 引用 的 方式 进行 访问 ， 





























到 其 他 文档 中 。 








表 等 信息 应 该 保存 在 单独 的 集合 中 ， 不 应 该 内 嵌 

















最 后 ， 如 有 果 共 些 字段 是 文档 数据 的 一 部 分 ， 那 么 





各 要 将 这 些 字段 内 嵌 到 文档 中 。 如 果 在 查询 文档 














时 经 常 需要 将 某 个 字段 排除 ， 那 么 这 个 字段 应 该 








放 在 另外 的 集合 中 ， 而 不 是 内 嵌 在 当前 的 文档 





中 。 表 8-1 给 出 了 一 























些 指导 原则 。 











8-1 ”内 髓 数据 与 引用 数据 的 比较 






































更 适合 内 嵌 更 适合 引 
子 文 档 较 小 子 文档 较 大 
数据 不 会 定期 改变 数据 经 常 改变 





最 终 数 据 一 致 即 可 





中 间 阶 段 的 数据 必须 一 至 





文档 数据 小 幅 增加 


文档 数据 大 幅 增 加 





数据 通常 需要 执行 二 次 查询 才能 获得 | 数据 通常 不 包含 在 结果 中 





快速 读 取 





快速 写 入 














的 字段 ， 以 及 它们 是 





假如 我 们 有 一 个 用 户 集 合 。 下 面 是 一 些 可 能 需要 














否 应 该 内 嵌 到 用 户 文档 中 。 






































。 用 户 首 选项 (account preferences) : 用 户 首 
选项 只 与 特定 用 户 相 关 ， 而 且 很 可 能 需要 与 
用 户 文档 内 的 其 他 用 户 信息 一 起 查询 。 所 以 
用 户 首选 项 应 该 内 藤 到 用 户 文档 中 。 


。 最 近 活 动 (recent activity) : 这 个 字段 取决 

E 如 果 这 
个 固定 长 度 的 字段 〈 比 如 最 近 的 10 次 活 
动 ) ， 那 么 应 该 将 这 个 字段 内 嵌 到 用 户 文档 
中 。 


。 好友 (friends) : 通常 不 应 该 将 好 友信 息 内 
拒 到 用 户 文档 中 ， 至 少 不 应 该 将 好 友信 息 完 
全 内 崔 到 用 户 文 档 中 。 下 节 会 介绍 社交 网 络 
应 用 的 相关 内 容 。 


。 所 有 由 用 户 产生 的 内 容 :不 应 该 内 嵌 在 用 
户 文档 中 。 






































































































































































































































8.1.2 ”基数 


























一 个 集合 中 包含 的 对 其 他 集合 的 引用 数量 叫做 基 
数 (cardinality) 。 常 见 的 关系 有 一 对 一 、 一 对 
多 、 多 对 多 。 假 如 有 一 个 博客 应 用 程序 。 每 篇 博 
ME (post) 都 有 一 个 标题 (titte) ， 这 是 一 

个 一 对 一 的 关系 。 每 个 作者 〈author) 可 以 有 多 





































































































篇 文章 ， 这 是 一 个 一 对 多 的 关系 。 每 篇 文章 可 以 














有 多 个 标签 (tag) ， 每 个 标签 可 以 在 多 篇 文章 中 
使 用 ， 所 以 这 是 一 个 多 对 多 的 关系 。 


在 MongoDB 中 ，many (£) 可 以 被 分 拆 为 两 个 子 


分 类 : many (多 ) 和 few (>) 


) 。 假 如 ， 作 者 和 





文章 之 间 可 能 是 一 对 少 的 关系 ; 每 个 作者 只 发 表 
了 为 数 不 多 的 几 篇 文章 。 博 客 文章 和 标签 可 能 是 








多 对 少 的 关系 : 文章 数量 实际 上 很 可 能 比 标签 数 
量 多 。 博 客 文 章 和 评论 之 间 是 一 对 多 的 关系 : 每 
篇 文章 都 可 以 拥有 很 多 条 评论 。 


















































只 要 确定 了 少 与 多 的 关系 ， 就 





可 以 比较 容易 地 在 









































内 峰 数 据 和 引用 数据 之 间 进 行 权 衡 。 通 常 来 


说 ,“ 少 ”的 关系 使 用 内 嵌 的 方式 会 比较 
好 ,“ 多 ”的 关系 使 用 引用 的 方式 比较 好 。 





























8.13 ” 好友、 粉丝 ， 以 及 其 
亲近 朋友 ， 远 离 敌 人 。 


Ae KI oR IL SSH 




















IRB AACA A LEE? AD m BER A ALAS Bt 
丝 、 好 友 ， 以 及 其 他 一 些 事物 。 对 于 这 些 高 度 关 





























联 的 数据 使 用 内 髓 的 形式 还 是 引用 的 形式 不 容易 




















权衡 。 这 一 节 会 介绍 社交 图 谱 


























数据 相关 的 注意 事 


ie 








项 。 通 常 ， 关 注 、 好 友 或 者 收藏 可 以 简化 为 一 个 











发 布 -订阅 系统 : 一 个 用 户 可 以 订阅 另 一 个 用 户 相 
关 的 通知 。 这 样 ， 有 两 个 基本 操作 需要 比较 高 

效 : 如 何 保存 订阅 者 ， 如 何 将 一 个 事件 通知 给 所 
有 订阅 者 。 

































































比较 常见 的 订阅 实现 方式 有 三 种 。 第 一 种 方式 是 
将 内 容 生产 者 内 髓 在 订阅 者 文档 中 : 














{ 
"Vid" : ObjectId("51250a5cd86041c7dca8 
"username" : "batman", 
"email" : "batman@waynetech.com" 
"following" 
ObjectId("51250a72d86041c7dca81910 
ObjectId("51250a7ed86041c7dca81936 
] 
} 























现在 ， 对 于 一 个 给 定 的 用 户 文 档 ， 可 以 使 用 形 如 
db.activities.find({"user" : {"$in" 
user["following"]}}) 的 方式 查询 该 用 户 感 兴 
趣 的 所 有 活动 信息 。 但 是 ， 对 于 一 条 刚刚 发 布 的 
活动 信息 ， 如 果 要 找 出 对 这 条 活动 信 | 息 感 兴趣 的 
所 有 用 户 ， 就 不 得 不 查询 所 有 用 户 

的 "following" 字 段 了 。 
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”id”: ObjectId("51250a7ed86041c7dca8 


"username" : "joker", 
"email" : "joker@mailinator.com" 
"followers" 


ObjectId("512516e8d86641c7dca81912 
ObjectId("51256a5cd86641c7dca8196f 
ObjectId("512516ffd86641c7dca81916 

















当 这 个 生产 者 新 发 布 一 条 信息 时 ， 我 们 立即 就 可 
以 知道 需要 给 哪些 用 户 发 送 通 知 。 这 样 做 的 缺点 
是 ， 如 果 需 要 找到 一 个 用 户 关注 的 用 户 列表 ， 就 
必须 查询 整个 用 户 集合 。 这 种 方式 的 优 缺 点 与 第 
一 种 方式 的 优 缺 点 正好 相反 。 


司 时 ， 这 两 种 方式 都 存在 另 一 个 问题 : 它们 会 使 
户 文档 变 得 越 来 越 大 ， 改 变 也 越 来 越 频繁 。 通 
常 ， ol ow ne ol Oe E T 
要 返回 : 查询 粉丝 列表 有 多 频繁 ? 如 果 用 户 比较 
频繁 地 关注 某 些 人 或 者 对 一 些 人 取消 关注 ， 也 会 
导致 大 量 的 碎片 。 因 此 ， 最 后 的 方案 对 数据 进 一 
步 范式 化 ， 将 订阅 信息 保存 在 单独 的 集合 中 ， 以 
这 些 缺 点 。 进行 这 种 程度 的 范式 化 可 能 了 点 
儿 过 了 ， 但 是 对 于 经 常 发 生变 化 而 且 不 需要 与 文 






















































































































































































































































































档 其 他 字段 一 起 返回 的 字段 ， 这 非常 有 
对 "followers" 字 上 段 做 这 文 种 范式 化 是 有 意义 的 。 


] 一 个 集合 来 保存 发 布 者 和 订阅 者 的 关系 ， 其 中 
的 文档 结构 可 能 如 下 所 示 : 








Sn 















































{ 
"_id" : ObjectId("51250a7ed86041c7dca8 
"followers" 
ObjectId("512510e8d86041c7dca81912 
ObjectId("51250a5cd86041c7dca8190f 
ObjectId("512516ffd86641c7dca81916 
] 
} 





























这 样 可 以 使 用 户 文档 比较 精简 ， 但 是 需要 额外 的 
查询 才能 得 到 粉丝 列表 。 由 于 "followers" 数 旨 
的 大 小 会 经 常 发 生变 化 ， 所 以 可 以 在 这 个 集合 上 
启用 "usePower0f2Sizes"， 以 保证 users 集 合 尽 
可 能 小 。 如 果 将 followers 集 合 保存 在 另 一 个 数据 
库 中 ， 也 可 以 在 不 过 多 影响 users 集 合 的 前 提 下 对 
其 进行 压缩 























Ss 













































































应 对 威 尔 : 惠 顿 “ 17 效应 


1 威 尔 : 惠 顿 (Wil Wheaton) : 美国 演员 ， 曾 出 
航 》， 并 在 《生活 大 爆炸 》 中 出 演 Sheldon 的 客 








际 迷 











《 星 
头 。 





演 过 
家 对 译 者 






































不 管 使 用 什么 样 的 策略 ， 内 符 字 段 只 能 在 子 文档 
或 者 引用 数量 不 是 特别 大 的 情况 下 有 效 发 挥 作 

。 对 于 比较 有 名 的 用 户 ， 可 能 会 导致 用 于 保存 
粉丝 列表 的 文档 溢出 。 对 于 这 种 情况 的 一 种 解决 
方案 是 在 必要 时 使 用 “连续 的 "文档 。 例 如 ; 






































































































































> db.users.find({"username" : "wil"}) 

{ 

"_id" : ObjectId("51252871d86041c7dca8 

"username" : "wil", 

"email" : "wil@example.com", 

"tbc" : [ 
ObjectId("512528ced86041c7dca8191e 
ObjectId("5126510dd86041c7dca81924 


] 

"followers" : [ 
ObjectId("512528a0d86041c7dca8191b 
ObjectId("512528a2d86041c7dca8191c 
ObjectId("512528a3d86041c7dca8191d 

] 


Aw 


"Vid" : ObjectId("512528ced86041c7dca8 

"followers" : [ 
ObjectId("512528F1d86041c7dca8191F 
ObjectId("512528F6d86041c7dca81920 








ObjectId("512528f8d86641c7dca81921 





] 
} 
{ 
"_id" : ObjectId("5126510dd86041c7dca8 
"followers" : [ 
ObjectId("512673e1d86041c7dca81925 
ObjectId("512650efd86041c7dca81922 
ObjectId("512650fdd86041c7dca81923 
] 
} 





























对 于 这 种 情况 ， 需 要 在 应 用 程序 中 添加 
从 "tbc" (to be continued) 数组 中 取 数 据 的 相关 
逻辑 。 

8.2 ”优化 数据 操作 

如 果 要 优化 应 用 程序 ， 首 先 必须 知道 对 读 写 性 能 
进行 评估 以 便 找到 性 能 瓶颈 。 对 读 取 操作 的 优化 
通常 包括 正确 使 用 索引 ， 以 及 尽 可 能 将 所 需 信 息 
放 在 单个 文档 中 返回 。 对 写 入 操作 的 优化 通常 
括 减少 索引 数量 以 及 尽 可 能 提高 更 新 效率 。 


经 常 需 要 在 写 入 效率 更 高 的 模式 与 读 取 效 率 更 高 


































































































































































































的 模式 之 间 权 衡 ， 所 以 必须 要 知道 哪 种 操作 对 你 
的 应 用 程序 更 重要 。 这 里 的 影响 因素 并 不 只 是 读 
取 和 写 入 的 重要 性 ， 也 包括 读 取 和 写 入 操作 的 频 
es ae 对 你 的 应 用 程序 来 说 写 入 操 作 更 加 
次 读 取 操作 ; “WA prea treaties 



































































































































8.2.1 优化 文档 增长 














更 新 数据 时 ， 需 要 明确 更 新 是 否 会 导致 文件 体积 
增长 ， 以 及 增长 程度 。 如 果 增 长 程度 是 可 预知 
的 ， 可 以 为 文档 预 留 足够 的 增长 空间 ， 这 样 可 以 
避免 文档 移动 ， 可 以 提高 写 入 速度 。 检 查 一 下 填 
充 因子 : 如 果 它 大 约 是 1.2 或 者 更 大 ， 可 以 考虑 手 
动 填充 。 


如 果 要 对 文档 进行 手动 填充 ， 可 以 在 创建 文档 时 
创建 一 个 占 空 间 比较 大 的 字段 ， 文 件 创建 成 功 之 
后 再 将 这 个 字段 移 除 。 这 样 就 提前 为 文档 分 配 了 
足够 的 空间 供 后 续 使 用 。 假 设 有 一 个 餐馆 评论 的 
集合 ， 其 中 的 文档 如 下 所 示 : 


{ 










































































































































































"_id" : ObjectId(), 
"restaurant" : "Le Cirque", 
"review" : "Hamburgers were overpriced 





"userId" : ObjectId(), 
"tags" : [] 
} 











"tags "字段 会 随 着 用 户 不 断 添加 标签 而 增长 ， 应 
程序 可 能 经 常 需要 执行 这 样 的 更 新 操作 : 



































> db.reviews.update({" id" : id}, 
... {"$push" : {"tags" : {"$each" : ["Fren 



































如 果 知 道 "tags" 通 常 不 会 超过 100 字 节 ， 可 以 寻 
工 为 文档 留 出 足够 的 填充 空间 ， 这 样 可 以 避免 更 
新 文档 时 发 生 文档 移动 。 如 果 不 为 文档 预 留 增 1 

空间 ， 那 么 每 当 "tags "字段 增长 时 ， 文 档 就 会 被 
移动 。 可 以 在 文档 最 后 添加 一 个 大 字段 (随便 
什么 名 字 ) 进行 手工 填充 ， 如 下 所 示 : 


{ 








Th 

















1 











7N 
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"id" : ObjectId(), 


"restaurant" : "Le Cirque", 
"review" : 


: "Hamburgers were overpriced 
"userId" : ObjectId(), 
"tags" : [], 

"garbage" : " 








可 以 在 第 一 次 插入 文档 时 这 么 做 ， 也 可 以 
在 upsert 时 使 用 "$setonInsert" 创 建 这 个 字 





段 。 

















更 新 文档 时 ， 总 是 用 "$unset" 移 除 "garbage" 字 


段 。 














> db.reviews.update({"_i 
. {"$push" : {"tags" 
"$unset" : {"garbage" 


d" : id}, 
: {"$each" : ["Fren 


: true}}) 

















如 果 "garbage" 字 段 存在 ， 








"$unset" 操 作 符 可 以 


将 其 移 除 ， 如 果 这 个 字段 不 存在 ，"$unset" 操 
作 符 什么 也 不 做 。 














如 果 文 档 中 有 一 个 字段 需要 1 











这 个 字段 放 在 文档 





首长 ， 应 该 尽 可 能 将 














最 后 的 位 置 ("garbage" 之 














前 ) 。 这 样 可 以 稍微 提高 一 点 点 的 性 能 ， 因 为 如 
果 "tags" 字 段 发 生 了 增长 ，MongoDB 不 需要 重 


写 "tags" 


8.2.2 H 


些 数据 只 








后 面 的 字段 。 
除 旧 数 据 














在 特定 时 间 内 有 用 ， 





几 周 或 者 几 个 月 




















之 后 ， 保 留 这 些 数据 只 是 在 ; 
























































良 费 存储 空间 。 Re 























种 常见 的 方式 用 于 删除 旧 数 据 : 使 用 固定 集合 


























使 月 


E Axe 


Hx TH] 





单 的 方式 

















第 二 种 方式 是 





月 TTL 集合 ， 








或 者 定 





期 删除 集合 。 











是 使 ) 




















ze, [fl 











a 
oO» 








使 用 TTI 焦 





确 地 控制 删除 
常 大 的 集合 来 
历 TTL 索 引 








来 删除 文档 。 


文档 的 时 机 。 
说 

















足够 的 写 入 量 


最 简单 的 方式 
利 








， 使 用 
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JEA Z 
集合 内 的 存活 期 。6.1 节 ! 


TILES 
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这 种 方式 可 能 不 够 快 : 它 通 过 遍 














HERS: 将 集合 大 小 设 为 
集合 被 填 满 时 ， 将 旧 数 


EA 
操作 造成 
居 时 会 大 大 降低 数 
有 详细 介绍 。 











定 集 合 会 对 























可 以 更 精 


晶 是 ， 对 于 写 入 量 非 














TILES 


能 够 承受 
日 数据 可 能 是 


KEJE 
绍 。 





Ts 6.24 




















最 后 方法 
文档 单独 使 用 




















是 使 用 


] 一 个 集 

















程序 就 开始 使 
合 ) ， 查 询 时 
进行 查询 。 
接 将 其 删除 。 











对 于 























3 新 月 份 的 集合 
要 对 当前 月 
6 个 月 之 





细 介 














份 和 之 前 
前 创建 的 
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} 
AR! 


: 例如 ， 每 个 月 
JOZE, M 
(初始 是 个 空 集 
At 份 的 集合 都 

， 可 以 直 






































这 种 方式 可 











晶 是 对 于 应 | 









































态 处 理 对 多 个 








以 应 对 任 





E 意 的 操作 中 


Es 























数据 库 的 查询 。 


程 序 来 说 会 比较 复杂 ， 因为 需要 
动态 的 集合 名 称 (或 者 数据 库 名 称 ) ， 也 要 动 


使 





8.3 ”数据库 和 集合 的 设计 


确定 了 文档 
样 的 集合 或 者 数 





A 








ay 











Ho 
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对 


据 库 上 者 
库 ， 在 磁盘 
独 的 文 从 


A 
如 ， 可 能 
要 对 它们 进行 








结构 2 








很 简单 ， 但 





Bh 











是 有 





通常 ， 
o MongoDBi 
组 合 











»9 R 

















EA 


























后 ， 接 下 来 就 要 确定 使 用 什么 











上 


库 来 保存 文档 。 





些 指导 原则 


通常 这 个 过 程 
需要 注意 。 




















具有 相近 模式 的 文档 
通常 不 允许 使 用 








应 该 放 在 相同 的 集合 



































Bb 么 这 些 文档 








， 如 果 有 些 文档 
应 该 放 在 
一 些 结构 非常 不 
聚合 ， 就 需要 让 
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但 是 如 果 























于 数据 库 来 说 ， 最 大 的 问题 是 锁 机 币 
BP 有 一 个 读 / 写 锁 


) 和 存储 。 





上 都 位 于 自己 的 文件 中 














库 


库 位 于 不 同上 
内 的 所 有 项 目 都 # 








位 于 同一 个 集 


| (每 个 数 
每 一 个 数据 
(通常 也 在 单 











F 夹 中 ) , 这 意味 着 ， 可 以 
的 磁盘 分 卷 。 























IA te 

















问 模式 ， 或 者 相近 的 访问 量 。 





ee RR a a 








所 以 ， 你 可 能 希望 数据 


近 的 “质量 ” 相近 的 访 


让 不 同 的 数据 














的 应 用 程 
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| PB ZS 





要 放 在 一 个 大 流 
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量 集合 中 ， 









































它 不 如 用 户 集合 重 














Be 























是 比 





要 ， 但 





PR 一 
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这 人 要 用 
插入 不 更 新 的 集 


























T) 、 





PE: 
户 ) 。 
据 量 
如 日 


你 可 和 


logs (H 
这 样 做 














可 外 
志 集合 多 ) 。 
负担 不 起 ， 











户 通知 ， 所 以 几 
按照 重要 性 进行 拆 分 ， 
的 好 处 是 ， 最 重要 的 数 
g 最 小 例如， 用户 集 合 内 的 数 


渚 在 SSD 上 。 或 者 对 


N O o 


Bia A RES BI = PA 
activities 〈 活 动 ) ~ users 
ERAH 
E Fy 7S 
将 所 有 数据 集 都 存储 在 SSD 上 
但 是 也 许可 以 只 将 用 户 集合 存 
用 户 和 集合 使 用 RAID10， 而 对 
















































































志和 活动 集合 





注 
通常 不 允许 直接 ; 
BY 




















fi} 
意 ， 使 用 多 个 数 
Bi Jee 。 例 如 ’ FIERA 


JRAIDO. 


中 库 时 有 一 些 限 制 : MongoDB 
各 数据 从 一 个 数据 库 移 到 另 一 个 
EA 数据 库 上 执行 





















































库 中 ， 也 无 法 使 


























MapReduce 的 结果 保存 到 B 数 据 
jrenameCollection 命 








令 将 集合 从 一 个 数据 库 
La 
J 








移动 到 另 一 个 数 ] 


据 库 (比如 ， 可 以 将 foo.bar 重 








名 为 foo.baz， 但 是 不 能 将 foo.bar 重 命名 为 
foo2.baz) 。 
8.4 一致 性 管理 


须要 明确 知道 应 
oa 高 。MongoDB 支 持 多 种 不 同 的 一 致 性 级 











程序 的 读 取 对 数据 一 致 性 的 























别 ， 从 每 次 都 读 到 完全 了 


所 数据 到 读 取 不 





E 确 的 最 





























确定 新 旧 程 度 的 数据 。 如 果 要 得 到 最 近 一 年 内 的 
活动 信息 报表 ， 可 能 只 要 求 最 近 这 些 天 的 数据 完 
全 准确 。 相 反 ， 如 果 要 做 实时 交易 ， 可 能 需要 即 
时 读 到 最 新 的 数据 。 


要 理解 如 何 获 得 这 些 不 同 级 别 的 一 至 性， 首先 要 
了 解 MongoDB 的 内 部 机 制 。 服 务 器 为 每 个 数据 库 
连接 维护 一 个 请 求 队列 。 客 户 端 每 次 发 来 的 新 请 
求 都 会 添加 到 队列 的 末尾 。 入 队 之 后 ， 这 个 连接 
上 的 请 求 会 依次 得 到 处 理 。 一 个 连接 拥有 一 个 一 
致 的 数据 库 视 图 ， 可 以 总 是 读 取 到 这 个 连接 最 新 
写 入 的 数据 。 


注意 ， 每 个 列队 只 对 应 一 个 连接 : 如 果 打 开 两 个 
shell， 连 接 到 相同 的 数据 库 ， 这 时 就 存在 两 个 不 
同 的 连接 。 如 果 在 其 中 一 个 shell 中 执行 插入 操 
作 ， 紧 接着 在 另 一 个 shell 中 执行 查询 操作 ， 新 插 
入 的 数据 可 能 不 会 出 现在 查询 结果 中 。 但 是 ， 如 
果 是 在 同一 个 shell 中 ， 插 入 一 个 文档 然后 执行 查 
询 ， 一 定 能 够 查询 到 刚 插 入 的 文档 。 想 手动 重 现 
这 种 问题 是 很 困难 的 ， 但 是 在 一 个 频繁 执行 插入 
和 查询 的 服务 器 上 很 可 能 会 发 生 。 经 常会 有 一 些 
开发 者 使 用 一 个 线程 插入 数据 ， 然 后 使 用 另 一 个 
线程 检查 数据 是 否 成 功 插入 。 片 刻 之 后 ， 刚 刚 
数据 看 上 去 好 像 并 没有 成 功 插 入 ， 但 是 这 些 数 扩 
忽然 就 出 现 了 。 
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使 用 Ruby、Python 和 Java 驱 动 程序 时 尤其 要 注意 
这 个 问题 ， 








对 为 这 三 种 语言 的 驱动 程序 都 使 用 了 














连接 池 (connection pool) 。 为 了 提高 效率 ， 这 些 














驱动 程序 会 建立 多 个 与 服务 器 之 间 的 连接 〈 也 就 
是 一 个 连接 池 ) ， 将 请 求 通过 不 同 的 连接 发 送 到 
服务 器 。 但 是 它们 都 有 各 自 的 机 制 来 保证 一 系列 





























相关 的 请 求 会 被 同一 个 连接 处 理 。 关 于 不 同 语言 
连接 池 的 详细 文档 ， 可 以 查看 MongoDB 
Wiki Chttp://dochub.mongodb.org/drivers/connections 


当 向 副本 集 备 份 节点 〈 参 见 第 11 章 ) 发 送 读 取 请 


求 时 ， 就 更 麻烦 了 。 副 本 集 的 数据 可 能 不 是 最 新 





















































的 ， 这 会 会 导致 读 取 到 的 数据 是 一 秒 钟 之 前 或 者 一 
分 钟 之 前 的 ， 甚 至 是 几 个 小 时 之 前 的 。 处 理 这 个 
问题 的 方式 有 好 几 种 ， 最 简单 的 一 种 是 将 所 有 读 
取 请 求 都 发 送 到 主 数据 库 ， 这 样 便 可 以 每 次 都 得 





到 最 
















































































新 最 准确 的 数据 。 也 可 以 设置 一 个 脚本 自动 




















检测 副本 集 是 否 落后 于 主 数据 库 ， 如 果 落 后 ， 就 


将 副本 集 设 为 维护 状态 。 如 果 你 的 副本 集 比 较 





小 ， 


取 请 求 发 送 到 主 数据 库 。 
































可 以 使 用 "w"” : setSize 执 行 安全 写 入 ， 如 
果 getLastError 没 能 成 功 返 回 ， 可 将 后 续 的 读 




















8.5 ”模式 迁移 

















随 着 





应 








程序 使 用 时 间 的 增长 和 需求 变化 ， 数 据 














库 模 式 可 能 也 需要 相 


式 可 以 实现 这 个 需求 ， 























小 心 保存 该 程序 使 | 





] 过 的 每 








应 地 增长 和 改变 。 有 几 种 方 
不 管 使 用 哪 种 方法 ， 都 要 
个 模式 。 








最 简单 的 方式 就 是 在 应 用 程序 需要 时 





模式 ， 以 确保 应 用 程 
(比如 ， 要 能 够 从 容 








是 某 些 字段 在 不 同 版 本 中 的 不 同类 型 ) 





J 能 会 导致 混乱 ， 






































改进 数 








司库 


序 能 够 支持 所 有 旧版 的 模式 
处 理 某 些 字段 的 缺失 ， 或 者 
。 这 种 方 
尤其 是 不 同 版 本 的 模式 之 间 

















冲突 时 。 例 如 ， 版 本 A 要 求 有 "mobile" 字 段 ， 


但 版 本 B 没 有 "mobile" 字 段 ， 却 需要 有 另外 一 个 
不 同 字 段 ， 同 时 还 有 个 版 本 C 认 为 "mobile" eB 




















是 可 选 的 。 为 了 满足 
人 码 变 得 一 团 糟 。 





























这 样 的 需求 可 能 会 逐步 把 代 





另 一 种 稍微 结构 化 一 点 儿 的 解决 方案 是 在 每 个 文 
档 中 包含 一 个 "version" 字 段 (或 者 "v") ， 使 


























这 个 字段 来 决定 应 
构 。 这 种 方式 对 模式 
对 多 个 版 本 都 有 效 。 
本 。 


最 后 一 种 方式 是 ， 当 
行 迁移 。 通 常 来 说 这 
允许 使 用 动态 模式 ， 
LE 




































































这 仍然 需 


当 模 式 发 生变 化 时 ， 
个 好 主意 : 
以 避免 执行 迁移， 
迁移 会 对 系统 造成 很 大 的 压力 。 但 是 ， 


并 不 是 


程序 能 够 接受 的 文档 结 
的 要 求 更 加 严格 : 文档 必须 





要 支持 各 种 旧版 
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如 果 决 定 





ee 
o MongoDB4 








的 多 文档 
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么 所 有 文档 
WA MongoDB ETE LFE h Aii, 最 终 
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需要 确保 所 有 文档 





都 被 成 功 更 
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都 成 功 更 新 
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部 分 没有 
8.6 Wi 





是 只 有 


部 分 文档 被 更 
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子 的 ( 原 
么 一 个 也 不 


新 ， 还 有 一 





适合 使 用 MongoDB 的 场景 











尽管 MongoDB 是 








as 


通用 型 数据 库 ， 























部 分 应 用 程序 中 ， 
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支持 下 面 这 些 应 月 








e MongoDB 不 支持 事务 (transaction) , 43 
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AIK o 





务 性 有 要 求 的 应 




















J 程序 不 建议 使 











MongoDB» 


可 以 
务 (transaction-li 
文档 时 ， 但 是 数据 库 并 不 能 强 
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么 做 。 因 此 ， 
设 定 的 某 利 
之 前 
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的 用 户 或 亚 
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在 多 个 不 同 维 
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aay 








可 以 让 所 有 客 








语义 规范 《比如 ， 执 行人 
前 都 要 先 检查 锁 ) ， 但 是 无 法 








EH 
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其 是 操作 上 

















可 以 用 在 大 





非 万 能 的 。MongoDB 不 








要 求 用 户 这 
端 都 遵守 你 
E 何 操 件 
阻挡 不 


简单 的 类 
































A 











变 成 
上 对 不 同类 型 
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接 ， 这 是 关系 型 
MongoDB 不 文 持 这 么 做 ， 以 后 也 入 
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数据 库 善 长 有 














的 事情 。 
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持 。 


最 后 ， 如 果 你 使 用 的 工具 不 文 持 MongoDB， 
了 可 能 你 应 该 选择 一 个 关系 型 数据 库 ， 而 不 


Fy 
是 MongoDB。 有 很 多 工具 并 不 支持 


MongoDB, MSQLAI - chemy 到 Wordpress。 
支持 MongoDB 的 工具 已 经 越 来 越 多 了 ， 但 是 
前 来 说 仍然 不 如 关系 型 数据 库 多 。 








































































































HO ”创建 副本 集 


本 章 介 绍 MongoDB 的 复制 系统 ， 副本 集 Creplica 
set) 。 本 章 主要 内 容 如 下 : 


本 集 的 概念 ; 
本 集 的 创建 方法 ; 
本 集成 员 的 可 用 选项 。 


9.1 复制 简介 


从 第 1 章 开 始 ， 我 们 使 用 的 一 直 是 单 台 服务 器 ， 

一 个 mongod 服 务 器 进程 。 如 果 只 是 用 作 学 习 和 开 
发 ， 这 是 可 以 的 ， 但 是 如 果 到 生产 环境 : ’ J 
险 会 很 高 ， 如 果 服 务 器 月 江 了 或 者 不 可 访问 了 怎 
么 办 ?数据 库 至 少 会 有 一 段 时 间 不 可 用 。 如 果 是 
硬件 出 了 问题 ， 可 能 需要 将 数据 转移 到 另 一 个 机 
器 上 。 在 最 坏 的 情况 下 ， 磁 盘 或 者 网 络 问题 可 能 
会 导致 数据 损坏 或 者 数据 不 可 访问 。 


使 用 复制 可 以 将 数据 副本 保存 到 多 台 服 务 器 上 ， 
建议 在 所 有 的 生产 环境 中 都 要 使 用 。 使 用 

MongoDB 的 复制 功能 ， 即使 一 台 或 多 台 服 务 器 出 
错 ， 也 可 以 保证 应 用 程序 正常 运行 和 数据 安全 。 


在 MongoDB 中 ， 创 建 一 个 副本 集 之 后 就 可 以 使 用 
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复种 
主 服务 器 

















务 器 的 数据 


| 功能 了 。 副 本 集 是 一 组 服务 器 ， 








其 中 有 


个 





























(primary) ， 
有 多 个 备份 服务 器 (secondary) , } 








副本 。 如 果 主 


于 处 理 


E ! 端 请 求 ， 还 
于 保存 主 服 


























服务 器 有 骨 尝 了， 备份 服 





务 器 会 自动 将 其 
器 。 








使 用 复制 功能 
然 可 以 从 副本 集 的 
服务 器 
































中 一 个 成 员 升 级 为 


时 ， 如 果 有 一 台 服 务 器 宕 机 了 ， 
其 他 服务 器 上 访问 数据 。 如 果 
上 的 数据 损坏 或 者 不 可 访问 ， 可 以 从 副本 
集 的 某 个 成 员 中 创建 一 份 





新 的 主 服务 
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新 的 数据 副本 。 











本 章 主 要 介绍 副本 集 以 及 如 何在 系统 上 建立 复制 








功能 





9.2 ”建立 副本 集 








为 了 快速 入 门 ， 本 节 会 
三 个 成 员 的 蝇 


一 个 包含 








引导 你 在 本 地 机 器 上 建立 
| 本 集 。 











这 些 设置 不 适用 于 


























生产 环境 ， 但 是 可 以 让 你 熟悉 复制 功能 以 及 相关 





的 各 种 配置 。 











一 不 节 例 子 中 的 数据 保存 在 /data/db 目 
录 下 ， 应 该 在 运行 这 些 代码 之 前 确保 这 个 目录 
存在 ， 而 且 当 前 用 户 对 这 个 目录 拥有 写 权限 ，。 


使 用 - -nodb 选 项 启动 一 个 mongo shell， 这 样 可 以 
启动 shell 但 是 不 连接 到 任何 mongod: 


$ mongo --nodb 
通过 执行 下 面 的 命令 就 可 以 创建 一 个 副本 集 : 

































































































































































> replicaSet = new ReplSetTest({"nodes" 








这 行 代 码 可 以 创建 一 个 包含 三 个 服务 器 的 副本 

集 : 一 个 主 服务 器 和 两 个 备份 服务 器 。 但 是 ， 在 
执行 下 面 两 个 命令 之 前 mongod 服 务 器 不 会 真正 启 
动 : 










































































> // 启动 3 个 mongod 进 程 
> replicaSet.startSet() 
> 


> // 配置 复制 功能 


























> replicaSet.initiate() 





现在 已 经 有 了 3 个 mongod 进 程 ， 分 别 运 行 在 
31000、31001 和 31002 端 口 。 这 3 个 进程 都 会 把 各 
自 的 日 志 输 出 到 当前 shell 中 ， 这 会 让 人 很 混乱 。 
所 以 先 把 这 个 shell 放 在 一 边 ， 再 开启 一 个 新 的 
shell 用 于 工作 吧 。 


在 第 二 个 shell 中 ， 连 接 到 运行 在 31000 端 口 的 
mongod: 








































































































> conn1 = new Mongo("localhost: 31000") 
connection to localhost: 31000 
testReplSet : PRIMARY> 

testReplSet:PRIMARY> primaryDB = conn1.get 
test 























注意 ， 当 连接 到 一 个 副本 集成 员 时 ， 提 示 符 变 成 
J"testReplSet: reais 其 中 
"PRIMARY" 是 当前 成 员 的 状 
态 ，"testReplSet" 是 副本 集 的 标识 

符 。"testReplSet" 是 ReplSetTest 使 用 的 默认 
名 称 ， 之 后 会 讲述 如 何 自 定 义 副 本 集 标识 符 。 


为 了 简洁 和 可 读 性 ， 之 后 的 例子 会 使 用 ">" 代 
¥"testReplSet : PRIMARY>" 提 示 符 。 
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在 连接 到 主 节点 的 连接 上 执行 jsMaster 命 令 ， 
可 以 看 到 副本 集 的 状态 : 









































> primaryDB.isMaster() 
{ 
"setName" : "testReplSet", 
"iismaster" : true, 
"secondary" : false, 
"hosts" : [ 
"wooster:31000", 
"wooster:31002", 
"wooster:31001" 
]， 
"primary" : "wooster:31000e", 
"me" : "wooster:31000", 
"maxBsonObjectSize" : 16777216, 


"localTime" : ISODate("2012-09-28T15:4 
"ok" : 1 








} 











isMaster 返 回 的 字段 有 点 儿 多 ， 其 中 有 一 个 很 
重要 的 字段 指明 了 这 是 一 个 主 节点 


("ismaster" : true) ， 副 本 集中 还 有 
个 hosts 列 表 。 






























































服务 器 返回 内 容 "ijsmaster" 


: false， 也 是 正常 的 。 可 以 从 "primary" 字 
段 获知 主 节点 是 哪 一 个 ， 然 后 重新 连接 到 主 节 
点 所 在 的 主机 /端口 就 可 以 了 。 


既然 已 经 连接 到 主 节 点 ， 就 做 一 些 写 入 操作 看 看 
会 有 什么 发 生 吧 ! 首先 ， 插 入 1000 个 文档 : 







































































> for (i=0; i<1000; i++) { primaryDB.coll. 
> 

> // 检查 集合 的 文档 数量 ， 确 保 真 的 插入 成 功 了 

> primaryDB.coll.count() 

1000 





























从 查 其 中 一 个 副本 集成 员 ， 验 证 一 下 其 中 是 否 有 
刚刚 写 入 的 那些 文档 的 副本 。 可 以 连接 到 任意 一 
个 备份 节点 : 
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Nyy 








> conn2 = new Mongo("localhost:31001") 
connection to localhost: 31001 

> secondaryDB = conn2.getDB("test") 
test 














备份 节点 可 能 会 落后 于 主 节点 ， 可 能 没有 最 新 号 
入 的 数据 ， 所 以 备份 节点 在 默认 情况 下 会 拒绝 读 
取 请 求 ， 以 防止 应 用 程序 意外 拿 到 过 期 的 数据 。 
习 此 ， 如 果 在 备份 节点 上 做 查询 ， 可 能 会 得 型 
个 错误 提示 ， 说 当前 节点 不 是 主 节点 。 

























































































> secondaryDB.coll.find() 
error: { "$err" : "not master and slaveok= 























这 是 为 了 保护 应 用 程序 ， 以 免 意外 连接 到 备份 节 
点 ， 读 取 到 过 其 数据。 如果 希 望 从 备份 节点 读 有 
数据 ， 需 要 设置 “从 备份 节点 读 取 数 据 没有 问 
题 "标识 ， 如 下 所 示 : 


> conn2.setSlaveOk() 
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主意 ，slaveOk 是 对 连接 (例子 中 是 conn2) 设 
置 的 ， 不 是 对 数据 库 (secondaryDB) 设置 的 。 


现在 就 可 以 从 这 个 备份 节点 中 读 取 数据 了 。 使 用 
普通 的 查询 : 


AY 
















































































secondary oe: coll. find() 

"Vid" : ObjectId("5037cac65f325793183390 
tzi id" : ObjectId("5037cac65f325793183390 
"_id" : ObjectId("5037cac65f325793183390 


"_id" : ObjectId("5037cac65f325793183390 
"_id" : ObjectId("5037cac65f325793183390 
a id" : ObjectId("5037cac65f325793183390 
ype "it" for more 


VvV 天 一 一 一 .一 一 一 


> secondaryDB.coll.count() 








|1000 | 


备份 





at 
Dr 


可 以 看 到 刚刚 写 入 的 所 有 文档 都 出 现在 
中 了 。 


现在 ， 试 着 在 上 执行 写 入 操作 : 


> secondaryDB.coll.insert({"count" : 1001} 
> secondaryDB.runCommand({"getLastError" 


{ 





























"err" : "not master", 
"code" : 10058, 

"n" : @, 

"lastOp" : Timestamp(86，6)， 
"connectionId" : 5， 

"ok" : 1 


} 


可 以 看 到 ， 不 能 对 备份 节点 执行 写 操作 。 备 份 节 
点 只 通过 复制 功能 写 入 数据 ， 不 接受 客户 端的 写 
入 请 求 。 


有 一 个 很 有 意思 的 功能 你 应 该 试 一 下 : 自动 故障 
转移 (automatic failover) 。 如 果 主 节点 挂 了 ， 其 
中 一 个 备份 节点 会 自动 选举 为 主 节 点 。 为 了 验证 
这 个 功能 ， 先 关 掉 主 节 点 : 









































































































































> primaryDB.adminCommand({"shutdown" : 1}) 








在 备份 节点 上 执行 jsMaster， 看 看 新 的 主 节 点 


是 哪 一 个 : 


> secondaryDB.isMaster() 

















的 内 容 如 下 所 示 : 


au 











返 


{ 





"setName" : "testReplSet", 
"ismaster" : true, 
"secondary" : false, 
"hosts" : [ 
"wooster: 31001", 
"wooster: 31000", 
"wooster : 31002" 
l 
"primary" : "wooster:31001", 
"me" : "wooster:31001", 
"maxBsonObjectSize" : 16777216, 
"localTime" ISODate("2012-09-28T16:5 


Tok" : 1 





} 


新 的 主 节点 也 可 以 是 其 他 服务 器 。 oe 
主 节 点 挂 了 的 备份 节点 会 成 为 新 的 主 节 点 。 现 在 


Nyy 






































可 以 向 新 的 主 节点 发 送 写 入 请 求 了 。 


isMaster 是 一 个 非常 老 的 命令 了 ， 那 时 副本 和 集 
还 没有 出 现 ，MongoDB 只 支持 主 从 复制 (master- 
slave replication) 。 所 以 它 与 副本 集 的 术语 有 些 
不 一 致 ，isMaster 中 的 主 节点 (master) 与 副本 
集中 的 主 节点 (primary〉 是 等 同 的 ， 从 节点 
(slave) 则 相当 于 备份 节点 〈secondary) 。 


在 副本 集 上 完成 这 些 操作 之 后 ， 从 第 一 个 shell 中 
将 其 关闭 。 这 个 shell 中 现在 应 该 充满 了 大 量 的 副 
本 集成 员 输 出 日 志 ， 敲 几 次 Enter 键 之 后 就 可 以 看 
aa 可 以 执行 下 面 的 命令 关闭 副本 
































































































































> replicaSet.stopSet() 


























AE! 你 刚刚 已 经 完成 了 创建 副本 集 、 使 用 如 
和 关闭 副本 集 的 操作 ! 


有 几 个 关键 的 概念 需要 注意 。 


。 客户 端 在 单 台 服务 器 上 可 以 执行 的 请 求 ， 都 
可 以 发 送 到 主 节 点 执行 〈 读 、 写 、 执 行 命 
令 、 创 建 索引 等 ) 。 

° 客户 端 不 和 外 在 备份 节点 上 执行 写 操作 。 
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。 默认 情况 下 ， 客 户 端 不 能 从 备份 节点 中 读 取 
数据 。 在 备份 节点 上 显 式 地 执 
行 sSetSlaveOk 之 后 ， 客 户 端 就 可 以 从 备份 
节点 中 读 取 数 据 了 。 


理解 这 些 基本 知识 之 后 ， 本 章 剩 余 的 部 分 是 集中 
讲述 在 各 种 实际 情况 下 应 该 如 何 配置 副本 集 。 记 
住 ， 如 果 希 望 在 实际 中 看 看 某 个 配置 或 者 选项 的 
效果 ， 随 时 可 以 回 到 ReplSetTest。 


9.3 配置 副本 集 


在 实际 的 部 署 中 ， 需 要 在 多 台 机 器 之 间 建 立 复制 
功能 。 本 节 会 完整 建立 一 个 真实 场景 下 的 副本 
， 你 在 99 己 的 应 用 程序 中 可 以 直接 使 用 。 


假设 你 有 一 个 运行 在 server-1:27017 上 的 单个 

mongod 实 例 ， 其 中 己 经 有 一 些 数据 (如 果 数 据 库 
中 现在 没有 数据 也 没关系 ， 只 是 数据 目录 会 为 空 
而 已 ) 。 首 先 要 为 副本 集 选 定 一 个 名 字 ， 名 字 可 
以 是 任意 的 UTF-8 字 符 串 。 


选 好 名 称 之 后 ， 使 用 --replSet name 选 项 重 
启 server-1。 例 如 : 















































































































































































































































































































































$ mongod --replSet spock -f mongod.conf -- 











现在 ， 使 用 同样 的 rep1Set 和 标示 符 (spock) 
再 启动 两 个 mongod 服 务 器 作为 副本 集中 的 其 他 成 
员 : 



































$ ssh server-2 
server-2$ mongod --replSet spock -f mongod 
server-2$ exit 
$ 
$ ssh server-3 
server-3$ mongod --replSet spock -f mongod 
server-3$ exit 












































只 有 第 一 个 副本 集成 员 拥 有 数据 ， 其 他 成 员 的 数 
据 目 录 都 是 空 的 。 只 要 将 后 两 个 成 员 添 加 到 副本 
集中 ， 它 们 就 会 自动 克隆 第 一 个 成 员 的 数据 。 


将 replSet 选 项 添加 到 每 个 成 员 各 有 自 的 
mongod.conf 文 件 中 ， 以 后 启动 时 就 会 自动 使 用 这 
个 选项 。 


现在 应 该 有 3 个 分 别 运行 在 不 同 服务 器 上 的 
mongod 实 例 了 。 但 是 ， 每 个 mongod 都 不 知道 有 其 
他 mongod 存 在 。 为 了 让 每 个 mongod 能 够 知道 彼此 
的 存在 ， 需 要 创建 一 个 配置 文件 ， 在 配置 文件 中 
列 出 每 一 个 成 员 ， 并 且 将 配置 文件 发 送 给 
server-1， 然 后 server-1 会 负责 将 配置 文件 传 
播 给 其 他 成 员 。 































































































































































































































































































于 先 创 建 配 置 文件 。 在 shell 
示 的 文档 : 























创建 一 


个 如 下 所 





> config = { 
"id" : "spock", 
"members" : [ 
{"_id" : ©, "host" 
{"_id" : 1, "host" 
{"_id" : 2, "host" 





"server-1:270 
"server-2:270 
"server-3:270 
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的 值 就 是 启动 时 从 命令 行 传递 进来 的 








" _id" 字 段 

















副本 集 名 称 





(在 本 例 中 是 "spock" ) 。 一 定 要 保证 这 个 名 称 








与 启动 时 传 入 的 名 称 一 致 。 


这 个 文档 的 剩余 部 分 是 一 个 副本 集成 员 数组 。 



























































这 个 config 对 象 就 是 副本 集 的 






























































其 发 送 给 其 中 一 个 副本 集成 员 。 
个 有 数据 的 服务 器 (server-1:27617) ， 使 
jconfig 对 象 对 副本 集 进行 初始 化 : 











配置 ， 
为 上 





ws) 











需要 将 


连接 至 


其 


N 





中 每 个 元 素 都 需要 两 个 字段 一 个 唯一 的 数值 类 
型 的 " id" 字段 ， 和 一 个 主机 名 《将 
机 名 替换 为 你 自己 实际 使 用 的 主机 


例子 中 的 主 
BHE) 。 


现在 


等 


| 一 











// 连接 





MmAvVvvVV Vv 


"info" : 
"ok" : 1 


} 


Z 


// 初始 化 副本 集 


rs.initiate(config) 


server- 





1 


db = (new Mongo("server-1:27617") ) .getDB 


"Config now saved locally. Should 














server-1 会 解析 这 个 配置 对 象 ， 然 后 向 其 他 成 






































员 发 送 消息 





， 提 醒 





on 


它们 使 用 















































都 配 














完成 之 后 ， 


它们 会 自 














然后 就 可 以 1 
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里 读 写 ;i 
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ASA 
除非 
副本 集 


后 ， 继 续 更 多 的 


“可惜 
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无 法 将 向 
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Page 日 
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有 了 这 样 
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副本 集 之 


























添加 








ASIA 








成 员 时 就 不 
































F 何 一 个 成 员 。 如 果 副 本 集 




















需要 停机 了 。 


FE 在 创建 一 个 全 新 的 副本 集 ， 可 以 将 配置 


新 的 配置 。 所 有 成 员 
动 选 出 一 个 主 节 点 ， 


机 服务 器 转换 为 副 
ke MERE 
也 想 将 它 配置 为 一 个 只 有 


文 
中 





己 经 有 一 个 有 





数据 的 成 员 ， 


























那 就 必须 将 配置 对 象 














发 送 给 这 个 和 
员 不 止 一 个 ， 








其 









































i BY 


























REI 

















和 有 数据 的 成 员 。 
b 么 就 无 法 初始 化 副本 集 。 
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他 方法 可 以 基 








flrs. initiate()m4 Hii 








个 全 局 变量 ， 
(可 以 执行 rs. 
这 些 函 数 大 多 


























te oy 





JN 是 数据 





AH 








下 面 的 数据 库 
等 价 的 : 


命令 


jmongo shell 来 配置 


其 中 包含 与 复 和 
help() 查 看 可 用 的 加 








如 果 拥 有 数据 的 成 














副本 
副本 集 进行 




















TAH 
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Irse rs 是 
上 相关 的 辅助 函数 
者 助 函数 ) 。 
器 。 例 如 ， 























装 





的 包 


Qi 


与 rs.initiate(config) 是 








> db.adminCommand({"replSetInitiate" 


: con 











对 辅助 函数 和 底 
常 好 的 ， 有 时 
数 要 简单 。 


























Ay 











层 的 数据 库 





命令 


都 做 些 了 解 是 非 











ae + 
市 
































数据 














IR 








E 命 令 比 使 用 辅助 函 





库 命 











9.3.2 ”网 络 注意 事项 


























副本 集 内 的 每 个 成 员 都 必须 能 够 连接 到 其 他 所 有 





























成 员 (包括 自身 ) 。 如 果 遇 到 某 些 成 员 不 能 到 达 
其 他 运行 中 成 员 的 错误 ， 就 需要 更 改 网 络 配置 以 
便 各 个 成 员 能 够 相互 连通 。 


另外 ， 副 本 集 的 配 














置 中 不 应 该 使 用 localhost 作 为 



































主机 名 。 如 果 所 有 副本 集成 员 都 运行 在 同一 全 机 





器 上 ， 那 么 localhost5 
在 一 台 机 器 上 的 副 


























st 可 以 被 正确 解析 ， 但 是 运行 
本 集 意义 不 大 ; 如果 副 本 集 是 


















































运行 在 多 台 机 器 上 的 ， 那 么 localhost 就 无 法 被 解 











析 为 正确 的 主机 名 。 
成 员 都 运行 在 同一 




















MongoDB 人 允许 副本 集 的 所 有 
台 机 器 上 ， 这 样 可 以 方便 在 本 
































地 测试 ， 但 是 如 果 
4jElocalhost +4 
LE 


FT o 














在 配置 中 混用 localhost 和 





LAH, MongoDB h 


9.4 修改 副本 集 配置 





可 以 随时 修改 副本 





集 的 配置 ， 可 以 添加 或 者 删除 





























成 员 ， 也 可 以 修改 
有 对 应 的 shell 辅 助 






































己 有 的 成 员 。 很 多 常用 操作 都 
函数 ， 比 如 ， 可 以 使 用 rs .add 






































为 副本 集 添加 新 成 











TR: 








> rs.add("server-4:27017") 











类 似 地 ， 也 可 以 从 副本 集中 删除 成 员 : 





> rs.remove("server-1:27017") 

Fri Sep 28 16:44:46 DBClientCursor::init c 

Fri Sep 28 16:44:46 query failed : admin.$ 
_id: "testReplSet", version: 2, member 
{ _id: 2, host: "ubuntu:3100@2" } ] } } 

Fri Sep 28 16:44:46 Error: error doing que 
failed src/mongo/shell/collection.js:1 

Fri Sep 28 16:44:46 trying reconnect to lo 

Fri Sep 28 16:44:46 reconnect localhost: 31 











注意 ， 删 除 成 员 时 〈 或 者 是 除 添加 成 员 之 外 的 其 
他 改变 副本 集 配 置 的 行为 ) ， 会 在 shell 中 得 到 很 
多 无 法 连接 数据 库 的 错误 信息 。 这 是 正常 的 ， 这 
配置 修改 成 功 了 。 重 新 配置 副本 集 
折 配 置 过 程 的 最 后 一 步 ， 主 节点 会 关 
闭 所 有 连接 。 因 此 ，shell 中 的 连接 会 短暂 断 开 ， 
然后 重新 自动 建立 连接 。 


重新 配置 副本 集 时 ， 主 节点 需要 先 退 化 为 普通 的 
备份 节点 ， 以 便 接受 新 的 配置 ， 然 后 会 恢复 。 要 
注意 ， 重 新 配置 副本 集 之 后 会 ， 副 本 集中 会 暂时 
没有 主 节 点 ， 之 后 会 一 切 恢复 正常 。 


可 以 在 shell 中 执行 rs.config() 来 查看 配置 修改 
是 否 成 功 。 这 个 命令 可 以 打印 出 副本 集 当 前 使 用 
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> rs.config() 
"id" : "testReplSet", 
"version" : 2, 
"members" : [ 
{ 
”id”: 1, 
"host" : "server-2:27017" 
}s 
{ 
"id ,2 
"host" : "server-3:27017" 
}s 
{ 
”id”: 3, 
"host" : "server-4:27017" 
} 
] 
} 
每 次 修改 副本 集 配 置 时 ，"version" 字 段 都 会 自 


增 ， 它 的 初始 值 为 1。 





除了 对 副本 集 添 加 或 者 
有 的 成 员 。 为 了 修改 副 
BER 





















































余 成 员 ， 也 可 以 修改 现 
成 员 ， 可 以 在 shell 





















































折 的 配置 文档 ， 然 后 调用 rs.reconfig。 假 









































设 有 如 下 所 示 的 配置 : 























> rs.config() 
”id”: "testReplSet", 
"version" : 2, 
"members" : [ 
{ 
"id" : 0, 
"host" : "server-1:27017" 
}s 
{ 
"ridas 15 
"host" : "10.1.1.123:27017" 
} 
{ 
vcda 2, 
"host" : "server-3:27017" 
} 
] 
} 























Ep" id" 为 1 的 成 员 地 址 用 了 正 而 不 是 主机 名 表 
示 ， 需 要 将 其 改 为 主机 名 表示 的 地 址 。 首 先 在 
shell 中 得 到 当前 使 用 的 配置 ， 然 后 修改 相应 的 字 

































































> var config = rs.config() 


> config.members[1].host = 


"server-2:27017 



























































数据 库 : 


现在 配置 文件 修改 完成 了 ， 


irs. reconfig# 











十 助 函 数 将 














需要 使 














新 的 配置 文件 发 送 给 




















> rs.reconfig(config) 














对 于 复杂 的 数据 集 配 置 修改 ，rs. 





















































比 rs.add 和 rs.r 
置 或 者 是 是 一 次 性 添 


emove £ 
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reconfigilll # 
J], ee 


或 者 删除 多 个 成 员 。 








这 个 命令 做 任何 合法 的 























他 TEEN 配置 























rs.reconfig. 


9.5 设计 副本 集 
为 了 外 ens Bit H 





的 如 














副本 集 配置 





















































当然 后 将 其 传 给 


WAR, Gas i 

















集 相关 概念 





需要 熟悉 。 











容 。 副 本 集中 和 
数 ”(majority) : 


下 一 章 会 讨 














ce, EVAR 








4 有 在 得 至 






































exe. 

















羊 细 讲 述 





重要 的 一 个 概念 是 大 多 

选择 主 节 点 时 需要 由 大 多 数 坟 
| 大 多 数 支持 时 才能 继续 作 
为 主 节点 ， 写 操作 被 复制 到 大 多 数 成 员 时 这 个 写 
操作 就 是 安全 的 。 这 里 
中 一 半 以 上 的 成 员 ”， 如 





的 大 多 数 被 定义 为 “副本 
表 9-1 所 示 。 











表 9-1 怎样 才 算 大 多 数 
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副本 集 的 配置 来 计算 的 。 























副本 集中 的 成 员 总 数 | E 
1 1 
2 2 
3 2 
4 3 
5 3 
6 4 
7 4 














意 ， 如 果 副 本 集中 有 些 成 员 挂 了 或 者 是 不 可 











， 并 不 会 影响 “大 多 数 "。 因 为 “大 多 数 " 是 直 








RA AT ALS AA 
不 可 用 ， 仍 然 有 2 个 可 以 正 
示 。 剩 余 的 2 个 成 员 已 经 无 法 达到 有 
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其 中 3 个 成 员 
妈 9-1 所 
本 集 “ 大 多 





数 "的 要 求 〈 在 这 个 例子 中 ， 





至 少 要 有 3 个 成 员 才 


EKER) ， 所 以 它们 无 法 选举 主 节 点 。 如 果 


这 两 个 成 员 中 有 一 个 是 主 
法 得 到 “大 多 数 ” 成 员 支 二 
No JURE, AAR 











节点 和 3 个 不 可 达成 员 。 





方 点 ， 当 它 注意 到 





它 无 





寺 时 ， 就 会 从 主 节点 J 
本 集中 会 包含 2 个 备份 
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图 9-1 由 于 副本 集中 只 有 少数 成 员 可 用 ， 所 有 
成 员 都 会 变 为 备份 节点 


可 能 会 有 很 多 人 觉得 这 样 的 规则 弱 爆 了 : 为 什么 
剩余 的 两 个 成 员 不 能 选举 出 主 节 点 呢 ? 问题 在 
于 ，3 个 不 可 达 的 成 员 并 不 一 定 是 真 的 挂 了 ， 可 
能 只 是 由 于 网 络 问题 造成 不 可 达 ， 如 图 9-2 所 示 。 
在 这 种 情况 下 ， 左 边 的 3 个 成 员 可 以 选举 出 一 个 
主 节 点 ， 因 为 3 个 成 员 可 以 达到 副本 集成 员 的 大 
多 数 ( 总 共 5 个 成 员 ) o 











































































































挂 了 


























于 成 员 来 说 ， 左 边 的 服务 器 会 觉得 右 
边 的 服务 器 挂 了 ， 碳 边 的 服务 器 也 会 觉得 左边 














下 ， 我 们 不 希望 两 边 的 网 络 各 自选 举 
点 : 那样 的 话 副本 集 就 会 拥有 两 个 主 








! 两 个 主 节点 都 可 以 写 入 数据 ， 这 样 整个 








天 本 集 的 数据 就 会 发 和 混乱。 只 有 达到 “大 多 

















况 下 才能 选举 或 者 维持 主 节点 ， 这 样 要 
求 是 为 了 避免 出 现 多 个 主 节点 。 









































个 主 节 点 ， 这 对 于 副本 集 的 配置 是 
































的 。 例 如 ， 对 于 上 面 描述 的 5 个 成 员 来 
[0 果 1、2、3 位 于 同一 个 数据 中 心 ， 而 4、5 


Ke 

















位 于 男 一 个 数据 中 心 。 这 样 ， 
里 ， 儿 乎 总 是 可 以 满足 “大 多 数 ” 这 个 条 件 〈 这 样 





就 可 以 比较 容易 地 判断 出 很 可 
的 网 络 错误 ， 而 不 是 数 和 











EPON ŽI 


在 第 1 个 数据 ! 
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能 是 数据 中 心 之 间 
的 错误 ) o 


一 种 常见 的 设置 是 使 用 2 个 成 员 的 副本 集 〈 这 通 


常 不 是 你 想 要 的 ) : 
点 。 假 如 其 中 一 个 成 员 不 可 用 
不 到 它 了 ， 如 图 9-3 所 示 。 在 这 
何 一 端 都 无 法 达 至 











一 个 主 节点 和 















































本 集会 退化 为 拥有 两 个 备份 节 











的 副本 集 。 









































图 9-3 ”如 果 成 员 总 数 是 侦 数 ， 成 员 
E 何 一 边 都 无 法 满足 “大 多 





不 同 的 网 络 中， 从 


数 ”的 条 件 








文 种 


KER n 
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因此 ， 通 常 不 建议 使 用 这 样 





一 个 备份 节 
个 成 员 就 看 
情况 下 ， 网 络 任 
所 以 这 个 副 
点 《没有 主 节点 ) 











的 配置 。 























下 面 是 两 种 推 


























荐 的 配置 方式 。 


。 将 “大 多 数 "成 员 放 在 同一 个 数据 中 心 ， 如 





平均 分 配 到 


























9-2 所 示 。 RATERS 








望 副 本 集 Va 
































F 这， 


能 够 正常 


ES 点 总 是 位 于 
话 ， 这 样 的 配置 会 比较 好 。 
运转 ， 就 会 有 一 个 主 节 点 。 但 是 ， 

















中 心 ， 而 且 你 希 
F 主 数据 中 心 的 
只 要 主 数据 中 心 

















如 果 主 数据 中 心 不 
心 的 成 员 无 法 选举 








在 两 个 数据 中 心 各 E 








E 么 备份 数 





HJ 








iy, J BHP 
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U 
LL 





主 节 点 。 




















放置 


数量 相等 的 成 员 ， 
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在 第 三 个 地 方 放置 


个 





























于 决定 胜 负 的 

















集成 员 。 如 果 两 个 
这 种 配置 会 上 
的 服务 器 都 司 
到 “大 多 数 ' 
散 到 三 个 地 方 。 
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CRUE o 





By 





J 本 
下 中 心 同等 重要 ， 那么 








大 








为 任意 一 个 数据 中 心 





> (BSE, RE 





找到 另 一 台 服 务 器 以 达 














就 需要 将 服务 器 分 














更 复杂 的 需求 需要 使 








不 同 的 本 








1 Be 
UL 


， 一 定 要 考虑 


























ye 
清楚 ， 


如 果 MongoDB 的 一 个 晶 
点 ， 


EÉ 
个 主 节 点 会 带 来 3 
































出 现 不 利 情况 时 ， 昌 


I 本 集 要 如 何 达 到 “大 


本 集 可 以 拥有 多 个 主 节 
| 这些 复杂 问题 就 迎刃而解 了 。 但 











Æ Z 











其 他 的 复杂 性 























的 情况 下 ， 就 需要 处 到 
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人 AN 





E 写 入 冲突 (例如 ，A 在 第 





E。 拥 有 两 个 主 节点 

















上 更 新 了 一 个 文档 ， 
上 删除 了 这 个 文档 ) 。 在 支持 多 线程 
系统 中 有 两 种 常见 的 冲突 处 至 


jB 在 男 一 个 主 
写 入 的 
方式 : 手工 解决 冲 


























突 或 者 是 让 系统 
种 方式 对 了 
确保 写 入 的 数据 不 会 























王选 一 个 作为 “赢家 ”。 
F 开 发 者 来 说 都 不 容易 实现 ， 





被 其 他 节 


晶 是 这 两 
对 为 无 法 
FR stk, 




















点 修改 。 














MongoDB 选 择 只 文 








过 持 单 











发 更 容易 ， 但 是 当 
程序 暂时 无 法 写 入 








选举 机 制 


Ww 


当 一 个 备份 节点 无 








副本 集 被 
数据 。 





法 与 主 


ET. A 
设 为 只 读 时 ， 将 导致 





可 以 使 开 








连 








通 时 ， 它 就 会 联 























节点 连 
本 











成 员 将 EE 


己 选 举 为 主 节 


WN 

















其 他 成 员 会 做 



































H 性 


JURE 











ee aes 
RNS BH 
员 可 以 被 选举 为 主 
































如 果 
中 “大 多 数 "成 员 的 








节点 ? 


要 求 被 选举 为 主 节 点 的 成 
投票 ， 


它 就 





的 检查 : 
希望 被 选举 为 主 节 
K? 有 没有 其 


4 身 是 否 
点 的 备份 
先 级 的 成 





能 
市 











更 高 优 








已 ob 


员 能 够 得 到 副本 外 
会 成 为 主 节 点 。 即 


[uy 








使 < 大 多 数 ” 成 员 中 














右 一 个 不 
I a 























举 就 会 取消 。 如 果 
希望 成 为 主 
它 就 会 否决 此 次 选 


在 日 志 中 可 以 看 到 和 














成 员 发 现任 


决 了 本 次 选举 ， 选 
E 何 原因 ， 表 明 当 前 

















点 的 成 员 不 应 该 成 为 主 节 点 ， 习 


举 。 
得 和 








况 ， 因 为 一 张 € 








否决 票 相当 于 10 000 张 赞成 更 。 


票数 为 比较 大 的 负数 的 情 


BA 





如 


FA BA BR EM, ASMA RE, AB 
么 就 可 以 在 消息 中 看 到 选举 结果 为 -9999 或 者 是 比 
较 相 近 的 负数 值 。 


Wed Jun 26 17:44:02 [rsMgr] replSet info e 
Wed Jun 20 17:44:02 [rsMgr] replSet couldn 





















































如 果 有 两 个 成 员 投 了 否决 票 ， 一 个 成 员 投 了 赞成 
票 ， 那 么 选举 结果 就 是 -19999， 依 次 类 推 。 这 些 
消息 是 很 正常 的 ， 不 必 担 心 。 


希望 成 为 主 节点 的 成 员 《〈 候 选 人 ) 必须 使 用 复制 
将 自己 的 数据 更 新 为 最 新 ， 副 本 集中 的 其 他 成 员 
会 对 此 进行 检查 。 复 制 操作 是 严格 按照 时 间 排 序 
的 ， 所 以 候选 人 的 最 后 一 条 操作 要 比 它 能 连通 的 
其 他 所 有 成 员 更 晚 〈 或 者 与 其 他 成 员 相 等 ) 。 


假设 候选 人 执行 的 最 后 一 个 复制 操作 是 123。 它 
能 连通 的 其 他 成 员 中 有 一 个 的 最 后 复制 操作 是 

124， 那 么 这 个 成 员 就 会 否决 候选 人 的 选举 。 这 
时 候选 和 人 会 继续 进行 数据 同步 ， 等 它 同步 到 124 
时 ， 它 会 重新 请 求 选举 (如 果 那 时 整个 副本 集中 
仍然 没有 主 节点 的 话 ) 。 在 新 一 轮 的 选举 中 ， 候 
如 候选 人 没有 其 他 不 合 规 之 处 ， 之 前 否决 它 的 成 
员 就 会 为 它 投 赞成 票 。 































































































































































































经 i 
































为 主 





1 了 “大 多 数 ” 的 赞成 票 ， 








sag 意 ; 每 个 成 员 都 只 


D 不 能 














它 就 会 成 





能 要 求 自己 被 





























推荐 其 他 成 员 被 




















9.6 成 员 配 置 选 项 


到 目前 为 止 ， 我 人 














有 同样 的 配置 。 


但 是 ， 有 时 我 人 


























员 都 完全 一 样 。 











] 建 立 的 副本 集中 所 有 成 员 都 
] 并 不 希望 每 人 








你 可 外 





EE 希望 让 某 个 成 员 拥 有 














个 
优 
成 为 主 节 点 的 权力 ， 或 者 是 让 某 个 成 员 对 客户 
不 可 见 ， 这 样 便 不 会 有 读 写 请 求 发 送 给 它 。 在 





请 成 为 主 节点 的 候选 人 
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本 集 配置 的 子 文档 

















项 (甚至 更 
的 选项 。 





多 选项 ) 。 





中 可 以 为 每 个 成 员 指 定 这 些 选 





9.6.1 选举 仲裁 者 

















使 用 量 比较 小 ， 














本 节 介 绍 可 以 对 成 员 使 用 




















上 面 的 例子 显示 了 有 具有 两 个 成 员 的 副本 集 在 “大 
多 数 ” 要 求 上 的 缺点 。 但 是 ， 很 多 人 的 应 用 程 
































并 不 想 保存 





份 数据 如 











EJT 
本 。 两 份 


a 
































副本 已 经 足够 了 ， 保 存 第 三 份 副 本 的 话 纯粹 是 浪 


费 人 力 、 物 力 和 财力 。 


对 于 这 种 部 署 ，MongoDB 支 持 一 种 特殊 类 型 的 成 
员 ， 称 为 仲裁 者 (arbiter) 。 仲 裁 者 的 唯一 作用 
就 是 参与 选举 。 仲 裁 者 并 不 保存 数据 ， 也 不 会 为 
客户 端 提 供 服务 : 它 只 是 为 了 帮助 具有 两 个 成 员 
的 副本 集 能 够 满足 "大 多 数 ” 这 个 条 件 。 


由 于 仲裁 者 并 不 需要 履行 传统 mongod 服 务 器 的 责 
任 ， 所 以 可 以 将 仲裁 者 作为 轻 量 级 进程 ， 运 行 在 
配置 比较 差 的 服务 器 上 。 如 果 可 能 ， 应 该 将 仲裁 
者 放 在 单独 的 故障 域 (failure domain) 中 ， 与 其 
他 成 员 分 开 。 这 样 它 就 可 以 以 “外 部 视角 ”来 看 待 
人 


月 动 仲裁 者 与 启动 普通 mongod 的 方式 相同 ， 
j"--replSet 副本 集 名 称 "和 空 的 数据 
可 以 使 用 rs.addArb() 辅 助 函 Hels RITE MA 
副本 集中 : 


































































































































































































































































































> rs.addArb("server-5:27017") 

















也 可 以 在 成 员 配 置 中 指定 arbiterOn1y 选 项 ， 这 
与 上 面 的 效果 是 一 样 的 : 





























> rs.add({"_id" : 4, "host" : "server-5:27 

















成 员 一 旦 以 仲裁 者 的 身份 添加 到 副本 集中 ， 它 就 
永远 只 能 是 仲裁 者 : 无 法 将 仲裁 者 重新 配置 为 非 
仲裁 者 ， 反 之 亦 然 。 


使 用 仲裁 者 的 另 一 个 好 处 是 : 如 果 你 拥有 的 节点 
数 是 偶数 ， 那 么 可 能 会 出 现 一半 节 点 投票 给 A， 
但 是 另 一 半 成 员 投票 给 B 的 情况 。 仲 裁 者 这 时 就 
可 以 投 出 决定 胜 负 的 关键 一 票 。 


1. 最 多 只 能 使 用 一 个 仲裁 者 


注意 ， 在 上 面 的 例子 中 ， 最 多 只 需要 一 个 仲裁 
者 。 如 果 节 点 数量 是 奇数 ， 那 就 不 需要 仲裁 者 。 
一 种 错误 的 理解 是 : 为 了 “以 防 万 一 ”， 总 是 应 该 
添加 额外 的 仲裁 者 。 但 是 ， 添 加 额外 的 仲裁 者 
并 不 能 加 快 选举 速度 ， 也 不 能 提供 更 好 的 数据 安 
全 性 。 


假设 有 一 个 3 成 员 的 副本 集 。 需 要 两 个 成 员 才 能 
组 成 “大 多 数 "， 才 能 选举 主 节点 。 如 果 这 时 添加 
了 一 个 仲裁 者 ， 副 本 集中 总 共 就 有 4 个 成 员 了 ， 
要 有 3 个 成 员 才 能 组 成 “大 多 数 "。 因 此 ， 副 本 和 集 
的 稳定 性 其 实 是 降低 了 : 原本 只 需要 67% 的 成 员 
可 用 ， 副 本 集 就 可 用 ; 现在 必须 要 有 75% 的 成 员 


































































































































































































































































































可 用 ， 副 本 集 才 可 用 。 


添加 额外 成 员 也 会 导致 选举 耗 时 变 长 。 由 于 添加 
了 仲裁 者 ， 现 在 副本 集 一 共 拥有 偶数 个 成 员 ， 这 
样 就 可 能 出 现 两 个 成 员 票 数 相同 的 情况 。 仲裁 者 
的 目的 应 该 是 避免 出 现 平 票 ， 而 不 是 导致 出 现 平 


ZN o 


2. 仲裁 者 的 缺点 


不 知道 应 该 将 一 个 成 员 节点 还 是 作为 仲 
裁 者 时 ， 应 该 将 其 作为 数据 节点 。 在 小 副本 集中 
FE pe ERE AS 些 操作 性 的 
任务 变 困难 。 假 设 有 一 个 副本 集 ， 它 有 两 个 
通 ” 成 员 ， 还 有 一 个 仲裁 者 成 员 ， 其 中 一 个 数据 
成 员 挂 了 。 如 果 这 个 数据 成 员 真 的 挂 了 〈 数 据 无 
法 恢复 ) ， 另 一 个 数据 成 员 成 为 主 节 点 。 这 时 整 
个 副本 集中 只 有 一 个 数据 成 员 和 一 个 仲裁 者 成 
eee cue re 
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相反 ， 如 果 拥 有 三 个 数据 成 员 ， 一 个 服务 器 挂 掉 
时 ， 副 本 集中 仍然 有 一 个 主 节 点 和 一 个 备份 节 
点 ， 不 会 影响 正常 运作 。 这 时 ， 可 以 用 剩余 的 那 
个 备份 节点 来 初始 化 一 个 新 的 备份 节点 服务 器 ， 
而 不 必 依 赖 于 主 节点 。 


在 上 面 两 个 数据 成 员 + 一 个 仲裁 者 成 员 的 情景 

中 ， 主 节点 是 仅 剩 的 一 份 完好 的 数据 ， 它 不 仅 要 
处 理应 用 程序 请 求 ， 还 要 将 数据 复制 到 另 一 个 新 
的 服务 器 上 。 


如 果 可 能 ， 尽 可 能 在 副本 集中 使 用 奇数 个 数据 成 
员 ， 而 不 要 使 用 仲裁 者 。 



















































































































































































9.6.2 ”优先 级 




















优先 级 用 于 表示 一 个 成 员 渴 望 成 为 主 节 点 的 程 
度 。 优先 级 的 取 值 范围 可 以 是 0~100， 默 认 是 1。 
将 优先 级 设 为 0 有 特殊 含义 : 优先 级 为 0 的 成 员 永 
远 不 能 够 成 为 主 节点 。 这 样 的 成 员 称 为 被 动 成 员 


(passive member) 。 


拥有 最 高 优先 级 的 成 员 会 优先 选举 为 主 节点 (只 
要 它 能 够 得 到 集合 中 大 多 数 "的 赞成 票 ， 并 且 数 
据 是 最 新 的 ) 。 假 如 在 副本 集中 添加 了 一 个 优先 
级 为 1.5 的 成 员 : 




























































































> rs.add({"_id" : 4, "host" : "server-4:27 




















假设 其 他 成 员 的 优先 级 都 是 1， 只 要 server-4 拥 有 
最 新 的 数据 ， 那 么 当前 的 主 节点 就 会 自动 退位 ， 
server-4 会 被 选举 为 新 的 主 节点 。 如 果 server-4 的 
数据 不 够 新 ， 那 么 当前 主 节点 就 会 保持 不 变 。 设 
置 优先 级 并 不 会 导致 副本 集中 选 不 出 主 节点 ， 也 
不 会 使 数据 不 够 新 的 成 员 成 为 主 节点 (一 直到 它 
的 数据 更 新 到 最 新 ) 。 


使 用 优先 级 时 有 一 点 需要 注意 : 修改 副本 集 配置 
时 ， 新 的 配置 必须 要 发 送 给 在 新 配置 下 可 能 成 为 
主 节 点 的 成 员 。 因 此 ， 无 法 在 一 次 reconfig 操 
作 中 将 当前 主 节点 的 优先 级 设置 为 0%， 也 不 能 对 
所 有 成 员 优 先 级 都 为 0 的 副本 集 执行 reconfig。 


优先 值 的 值 只 会 影响 副本 集成 员 间 相对 优先 级 大 
小 关系 。 如 果 某 个 副本 集 3 个 成 员 的 优先 级 是 
500、1、1， 男 一 个 副本 集 3 个 成 员 的 优先 级 是 
2、1、1， 那 么 它们 的 行为 是 一 样 的 。 














































































































































































































































































































9.6.3 ”隐藏 成 员 





客户 端 不 会 向 隐藏 成 员 发 送 请 求 ， 隐 藏 成 员 也 不 
会 作为 复制 源 《〈 尽 管 当 其 他 复制 源 不 可 用 时 隐藏 









































成 员 也 会 被 使 用 ) 。 因 此 ， 很 多 人 会 将 不 够 强大 
的 服务 器 或 者 备份 服务 器 隐藏 起 来 。 


假设 有 一 副本 集 如 下 所 示 : 












































> rs.isMaster() 
{ 

"hosts" : [ 
"server-1:27107", 
"server-2:27017", 
"server-3:27017" 

]; 

} 














为 了 隐藏 server-3， 可 以 在 它 的 配置 中 指定 
hidden : true。 只 有 优先 级 为 0 的 成 员 才 能 被 
隐藏 (不 能 将 主 节点 隐藏 〉: 








> var config = rs.config() 

> config.members[2].hidden = 6 
0 

> config.members[2].priority = 
0 

> rs.reconfig(config) 





现在 ， 执 行 isMaster() 可 以 看 到 : 

















> rs.isMaster() 
{ 

"hosts" : [ 
"server-1:27107", 
"server-2:27017" 

]， 

} 





IR 


使 用 rs.status() 和 rs.config() 能 够 看 到 隐藏 
成 员 ， 隐 藏 成 员 只 对 isMaster() 不 可 见 。 客 户 
端 连接 到 副本 集 时 ， 会 调用 isMaster() 来 查看 
可 用 成 员 。 因 此 ， 隐 藏 成 员 不 会 收 到 客户 端的 读 


[5 













































































要 将 隐藏 成 员 设 为 非 隐 藏 ， 只 需 将 配置 中 的 
hidden 设 为 false 就 可 以 了 ， 或 者 删除 hidden 选 








9.6.4 延迟 备份 节点 


























数据 可 能 会 因为 人 为 错误 而 遭受 毁灭 性 的 破坏 : 
可 能 有 人 不 小 心 删除 了 主 数据 库 ， 或 者 刚 上 线 的 
新 版 应 用 程序 有 一 个 严重 bug， 把 所 有 数据 都 变 
成 了 垃圾 。 为 了 防止 这 类 问题 ， 可 以 使 










































































jslaveDelay 设 置 一 个 延迟 的 备份 节点 。 


延迟 备份 节点 的 数据 会 比 主 节 点 延迟 指定 的 时 间 
EME) ， 这 是 有 意 为 之 。 这 样 ， 如 果 有 人 
不 小 心 摧毁 了 你 的 主 集合 ， 还 可 以 将 数据 从 先前 
的 备份 中 恢复 过 来 。12.4.7 节 有 详细 介绍 。 


slaveDelay 要 求 成 员 的 优先 级 是 0。 如 果 你 的 应 
会 将 读 请 求 路 由 到 备份 节点 ， 应 该 将 延迟 备份 
节点 隐藏 掉 ， 以 免 读 请 求 被 路 由 到 延迟 备份 节 
点 。 


























































































































9.6.5 创建 索引 











有 时 ， 备 份 节点 并 不 需要 与 主 节 点 拥有 相同 的 索 
引 ， 甚 至 可 以 没有 索引 。 如 果 某 个 备份 节点 的 用 
途 仅 仅 是 处 理 数 据 备份 或 者 是 离线 的 批量 任务 ， 
那么 你 可 能 希望 在 它 的 成 员 配 置 中 指 
定 "buildIndexs"” : false。 这 个 选项 可 以 阻 
止 备份 节点 创建 索引 。 


这 是 一 个 永久 选项 ， 指 定 了 "buildIndexes" : 
false 的 成 员 永 远 无 法 恢复 为 可 以 创建 索引 的 “ 正 
常 ?成 员 。 如 果 确 实 需要 将 不 创建 索引 的 成 员 人 4 
改 为 可 以 创建 索引 的 成 员 ， 那 么 必须 将 这 个 成 员 
从 副本 集中 移 除 ， 再 删除 它 的 所 有 数据 ， 最 后 再 
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We 


















































将 它 重 新 添加 到 副本 集中 ， 并 且 允 许 它 重 新 进行 
数据 同步 。 


男 外 ， 这 个 选项 也 要 求 成 员 的 优先 级 为 0。 
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副本 集 的 组 成 
是 如 何 组 织 在 一 起 


本 章 介 绍 副本 集 的 各 个 
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10.1 同步 











复制 用 于 在 多 台 朋 
是 使 用 操作 日 a 








的 复制 功能 








副本 集成 员 如 何 复制 新 数据 ; 
新 成 员 开 始 工 











作 ; 
能 的 服务 器 和 网 络 故障 。 









































以 知道 
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Bed 














原 提供 给 其 人 








的 操作 

















由 成 员 使 用 ， 如 图 1 















































再 将 这 些 


























到 某 个 操 
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青 况 CR 





的 ， 操 作 日 


R 务 器 之 间 备 份 数据 。MongoDB 
志 oplog 实 现 
志 包含 了 主 节点 的 每 一 次 写 操作 。oplog 是 主 节点 
的 local 数 据 库 中 的 一 个 固定 集 
查询 这 个 集合 就 可 


每 个 备份 节点 都 维 
次 从 主 节 点 复种 
可 以 作为 同步 ; 
所 示 。 备 份 节点 从 当前 使 用 


ma AAS 





合 。 备 份 节点 通过 
需要 进行 复制 的 操作 。 


9 己 的 oplog， 记 录 着 每 一 
。 这 样 ， 每 个 成 员 都 


0-1 


的 同步 源 中 获取 需要 
FE， 然 后 在 自己 的 数据 集 上 执行 这 些 操 
Et 操作 写 入 自己 的 oplog。 如 果 壳 








4 有 当 同 步 源 的 数 寺 





EIR 





坏 或 者 数据 与 主 节 点 不 一 致 时 才 可 能 发 生 ) ， 那 








么 备份 节点 就 会 停止 从 当前 的 同步 源 复制 数据 。 
让 开局 





图 10-1 ”oplog 中 按 顺 序 保存 着 所 有 执行 过 的 写 

操作 。 每 个 成 员 都 维护 着 一 份 自己 的 oplog， 每 

个 成 员 的 oplog 都 应 该 跟 主 节点 的 oplog 完 全 一 致 
(可 能 会 有 一 些 延 迟 ) 


如 果 某 个 备份 节 于 某 些 原因 挂 掉 了 ， 当 它 重 
新 启动 之 后 ， A a 
始 进行 同步 。 由 于 复制 操作 是 先 复制 数据 
再 号 入 oplog， 所 以 ， 备 份 节点 可 能 会 在 已 经 同步 
age nae. MongoDB 在 设计 
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执行 多 次 ， 
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钟 内 写 入 1 KB 条 操作 日 志 
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个 受 Ye 


除了 1 000 000 个 文档 


条 日 志 
行 db .col1. 
了 么 oplog 中 就 会 有 1 000 000 条 操作 
志 对 应 一 个 被 删除 的 文档 。 
操作 ，oplog 很 


1 KB 的 写 入 i 


的 ， 
通常 ，oplog 使 用 空 
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青 求 ， 那么 oplog 很 可 能 也 
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10.1.1 初始 化 同步 
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1 本 集中 








确定 是 否 可 以 从 某 个 成 员 那 
A 它 会 尝试 从 员 


行 的 话 ， 





的 成 员 局 动 之 后 ， 就 
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和 到 多 个 文档 
更 新 ) ，oplog 
单个 操作 会 影响 
都 会 对 应 oplog 
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三 | 
日 是 ， 有 
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志 ， 每 条 日 
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会 被 填 满 。 


执行 大 上 
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身 状态 ， 
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这 个 过 程 就 











里 进行 同步 。 如 
1 本 的 另 一 个 成 员 那 上 
是 初始 化 同步 





E 
IN 


E 














~、 
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(initial syncing) ， 包 括 几 个 步骤 ， 可 以 从 








mongod 的 日 志 中 看 到 。 


1. 首先 ， 这 个 成 员 会 做 一 些 记录 前 的 准备 
作 : 选择 一 个 成 员 作 为 同步 源 ， 在 local.me 
中 为 自己 创建 一 个 标识 符 ， 删 除 所 有 已 存在 
的 数据 库 ， 以 一 个 全 新 的 状态 开始 进行 同 
H: 






















































































Mon Jan 30 11:09:18 [rsSync] replSet i 
Mon Jan 30 11:09:18 [rsSync] replSet s 
Mon Jan 30 11:09:18 [rsSync] build ind 
Mon Jan 30 11:09:18 [rsSync] build ind 
Mon Jan 30 11:09:18 [rsSync] replSet i 
Mon Jan 30 11:09:18 [rsSync] dropAllDa 








注意 ， 在 这 个 过 程 中 ， 所 有 现 有 的 数据 都 会 
被 删除 。 应 该 只 在 不 需要 保留 现 有 数据 的 情 
况 下 做 初始 化 同步 (或 者 将 数据 移 到 其 他 地 
Fi) ， 因 为 mongod 会 首先 将 现 有 数据 删除 。 


2. 然后 是 克隆 (cloning) ， 就 是 将 同步 源 的 所 
有 记录 全 部 复制 到 本 地 。 这 通常 是 整个 过 程 
中 最 耗 时 的 部 分 : 

Mon Jan 30 11:09:18 [rsSync] replSet i 


Mon Jan 36 11:09:18 [rsSync] replSet i 
Mon Jan 36 11:09:18 [FileAllocator] al 






















































































filling with zeroes... 

















3. 然后 就 进入 oplog 同 步 的 第 一 步 ， 克 隆 过 程 中 
的 所 有 操作 都 会 被 记录 到 oplog 中 。 如 果 有 文 








档 在 克隆 过 程 中 被 移动 了 ， 就 可 能 会 被 遗 
漏 ， 


Ob SE 
Hem 





















































导致 没有 被 克隆 ， 对 于 这 样 的 文档 ， 可 
要 重新 进行 克隆 ; 














Mon 
Mon 
Mon 


Mon 


Mon 


Jan 36 15:38:36 [rsSync] oplog syn 

Jan 36 15:38:36 [rsBackgroundSync ] 

Jan 30 15:38:37 [rsSyncNotifier] r 

server-1:27017 

Jan 36 15:38:37 [repl writer worke 

failed: 

{ ts: Timestamp 1352215827000|17, 
ns: "db1.someColl", 02: { _id: O 
o: { $set: { count.@: 2, count. 

Jan 36 15:38:37 [repl writer worke 

adding missing object 

Jan 36 15:38:37 [repl writer worke 

not found on source. presumably de 






































是 一 个 比较 粗略 的 日 志 ， 显 示 了 有 文档 
重新 克隆 的 情况 。 在 克隆 过 程 中 也 可 能 















































遗漏 文档 ， 这 取决 于 流量 等 级 和 同步 源 


操作 类 型 。 











4. 接 下 来 是 oplog 同 步 过 程 的 第 二 步 ， 用 于 将 第 
一 个 oplog 同 步 中 的 操作 记录 下 来 。 


























Mon Jan 36 15:39:41 [rsSync] oplog syn 





这 个 过 程 比 较 简 单 ， 也 没有 太 多 的 输出 。 只 












































有 在 没有 东西 需要 克隆 时 ， 这 个 过 程 才 会 与 


第 一 个 不 同 。 








5. 到 目前 为 止 ， 本 地 的 数据 应 该 与 主 节 点 在 某 

















个 时 间 点 的 数据 集 完全 一 致 了 ， 可 以 开始 创 























建 索引 了 。 如 果 集合 比较 大 ， 或 者 要 创建 的 








索引 比较 多 ， 这 个 过 程 会 很 耗 时 间 : 








Mon 
Mon 
Mon 
Mon 





Jan 
Jan 
Jan 
Jan 


36 15:39:43 [rsSync] replSet i 
36 15:39:43 [rsSync] replSet i 
36 15:39:43 [rsSync] build ind 
36 15:39:44 [rsSync] build ind 


1.96 secs 








6. 如 果 当 前 节点 的 数据 仍然 远 远 落 后 于 同步 

















ERII 














源 ， 那 么 oplog 同 步 过 程 的 最 后 一 步 就 是 将 创 
期 间 的 所 有 操作 全 部 同步 过 来 ， 防 止 





该 成 员 成 为 备份 节点 。 











Tue Nov 6 16:05:59 [rsSync] oplog sync 

















7. 现在 ， 当 前 成 员 已 经 完成 了 初始 化 同步 ， 切 
换 到 普通 同步 状态 ， 这 时 当前 成 员 就 可 以 成 
为 备份 节点 了 : 


























Mon Jan 36 16:07:52 [rsSync] replSet i 
Mon Jan 30 16:07:52 [rsSync] replSet s 
Mon Jan 36 16:07:52 [rsSync] replSet S 























如 果 想 跟踪 初始 化 同步 过 程 ， 最 好 的 方式 就 是 查 
看 服务 器 日 志 。 


从 操作 者 的 角度 来 说 ， 初 始 化 同步 是 非常 简单 
的 : 使 ] 空 的 数据 目录 局 动 mongod 即 可 。 但 是 ， 
更 多 时 候 可 能 需要 从 备份 中 恢复 〈 第 22 章 会 详 名 
介绍 ) 而 不 是 进行 初始 化 同步 。 从 备份 中 恢复 
速度 比 使 用 mongod 复 制 全 部 数据 的 速度 快 得 多 。 


克隆 也 可 能 损坏 同步 源 的 工作 集 (working 

set) 。 实 际 部 署 之 后 ， 可 能 会 有 一 个 频繁 使 用 的 
数据 子 集 常 驻 内 存 〈 因 为 操作 系统 要 频 系 访 问 这 
个 子 集 ) 。 执 行 初始 化 同步 时 ， 会 强制 将 当前 成 
员 的 所 有 数据 分 页 加 载 到 内 存 中 ， 这 会 导致 需要 
频繁 访问 的 数据 不 能 常 驻 内 存 ， 所 以 会 导致 很 多 
请 求 变 慢 ， 因 为 原本 只 要 在 RAM《〈 内 存 ) 中 就 可 
以 处 理 的 数据 要 先 从 磁盘 上 加 载 。 不 过 ， 对 于 比 
较 小 的 数据 集 和 性 能 比较 好 的 服务 器 ， 初 始 化 同 


































































































aH 














































































































an 

















步 仍 然 


BLA AA 

















A) 








初始 化 同步 过 
(克隆 ) 或 者 第 (5) 步 (创建 索引 ) 耗费 了 太 长 的 


新 成 员 就 与 





时 间 。 这 种 情况 下 ， 





ke} fi 4 








的 选项 。 


旦 中 经 常 遇 到 的 问 





题 











S 


是 ， 


第 (2) 步 
步 源 的 





oplog“ fii Ti”: 
RR HY BH 





同步 源 可 能 会 将 新 成 员 需 要 复种 


掉 。 


这 个 问题 没有 有 效 的 解决 办 法 ， 
同步 ， 或 者 是 从 备份 中 恢复 数据 。 如 
同步 源 的 oplog 脱 节 ， 初 始 化 同步 就 无 


执行 初始 化 
果 新 成 员 与 

















新 成 员 远 远 落 后 于 
同步 速度 赶不上 同步 源 的 变化 速度 ， 
CAN Hi a itt 








VAY 


ip 














法 正常 进行 。 


H 


10.1.2 ”处 理 








下 一 节 会 


=] 


ii 





MIA Bd 


更 深入 地 介绍 














如 果 
么 这 个 备份 
份 节点 无 法 吕 








备份 节点 远 远 落后 
日 的 (stale) 


节点 就 是 陈 | 
民 上 同步 源 上 








的 节奏 ， 因 














同步 源 


= 





’ 


某 些 





绍 。 


+ BURT 


除非 在 不 太 忙 时 











同步 源 当 前 的 操作 ， 那 
。 陈 旧 的 备 





为 同步 源 上 上 








REY 





页 先 太 多 太 多 : 如 
节点 需要 跳 过 一 些 操作 。 如 果 从 备份 节 








IN 





By 





























tit, SAS 


量 超过 了 自身 处 理 








多 的 读 请 求 ， 
旧 。 





这 些 情 


青 况 都 可 能 导致 备份 节 





点 陈 


的 


业 续 进行 同步 ， 备 份 
点 曾经 停 


能 力 , 或 者 是 有 太 








他 成 员 TAs y 


一 个 备份 节点 陈旧 











Fl 


























于 处 理 那些 落 























FE 

















j 步 。 如 果 任 何 


Ay 


值 ， 





> 后 ， 它 会 查看 
[果菜 个 成 员 的 oplog 足 够 i 
的 操作 ， 就 从 i 



































i 


成 员 需 要 


份 中 恢复 ) 。 





为 了 避免 陈旧 备份 节点 的 出 
较 大 的 oplog 保 存 足够 多 的 操作 

















大 的 oplog 会 占 ) 


是 一 个 比较 好 的 折衷 


j 更 多 的 磁盘 








1 本 集中 的 
详尽 ， 可 以 
这 个 成 员 处 进行 
个 成 员 的 oplog 都 没有 参考 价 

那么 这 个 成 员 上 的 复制 操作 就 会 中 止 ， 这 个 
新 进行 完全 同步 (或 者 是 从 最 近 的 备 





现 ， 让 主 节点 使 月 
的 。 


日 志 是 


空间 。 


很 重 
通常 来 


要 
说 ， 


























HEK 
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为 磁盘 
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多 信息 ，12.4.6 节 会 


10.2 心跳 


中 使 ) 














的 oplog 只 有 一 
] 太 多 RAM。 关 于 oplog 空 
详细 介绍 。 


会 越 来 越 便 




















\ 部 分 ， 





Al stk 























fa] i} 

















每 个 成 员 都 需要 知 i 
节点 ?哪个 可 以 作为 同步 源 ?” 哪 个 提 
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a= 








维护 集合 的 最 
向 其 他 成 员 发 送 一 
request) 。 


每 个 成 员 的 状态 。 














心跳 最 重要 的 功能 之 一 就 是 让 主 


新 视 
心跳 请 求 的 信 ， 








区 
个 心跳 请 























他 成 员 的 状态 : 


息 量 


yi 





5K Cheartbeat 
zj aE? 是 小 四 



































节点 知道 自 


的 更 


(个 是 主 
HET? 为 了 
， 每 个 成 员 每 隔 两 秒 钟 就 会 


] 于 检查 


I A 
Lo KE 





否 满 足 集 合 “ 大 多 数 ” 的 条 件 。 如 果 主 节点 不 再 得 
到 “大 多 数 "服务 器 的 支持 ， 它 就 会 退位 ， 变 成 备 
份 节点 





成 员 状 态 




















各 个 成 员 会 通过 心跳 将 自己 的 当前 状态 告诉 其 他 
成 员 。 ges a out 主 节 点 和 备 
份 节点 。 还 有 其 他 一 些 常见 状态 。 


e STARTUP 
成 员 刚 启动 时 处 于 这 个 状态 。 在 这 个 状态 
J MongoDB 会 党 试 加 载 成 员 的 副本 集 配 

。 配 置 加 载 成 功 之 后 ， 就 进入 STARTUP2 
状态 。 


STARTUP2 




























































































整个 初始 化 同步 过 程 都 处 于 这 个 状态 ， 但 
如 果 是 在 普通 成 员 上 ， 这 个 状态 只 会 持续 
秒 钟 。 在 这 个 状态 下 ，MongoDB 会 创建 几 
线程 ， 用 于 处 理 复制 和 选举 ， 然 后 就 会 切换 
到 RECOVERING 状 态 。 





on 





















































a 











e RECOVERING 








这 个 状态 表明 成 员 运 转正 常 ， 但 是 暂时 还 不 
能 处 理 读 取 请 求 。 如 果 有 成 员 处 于 这 个 状 
态 ， 可 能 会 造成 轻微 的 系统 过 载 ， 以 后 可 能 
会 经 常见 到 。 
启动 时 ， 成 员 需 要 做 一 些 检查 以 确保 自己 处 
于 有 效 状 态 ， 之 后 才 可 以 处 理 读 取 请 求 。 在 
启动 过 程 中 ， 成 为 备份 节点 之 前 ， 每 个 成 员 
都 要 经 历 RECOVERING 状 态 。 在 处 理 非 常 耗 
时 的 操作 时 ， 成 员 也 可 能 进入 RECOVERING 
状态 。， 比 如 压缩 或 者 是 响应 
replSetMaintenance 命 令 ( 详 见 12.3.3 
节 ) 。 

当 一 个 成 员 与 其 他 成 员 脱节 时 ， 也 会 进 

入 RECOVERING 状 态 。 通 常 来 说 ， 这 时 这 个 
成 员 处 于 无 效 状态 ， 需 要 重新 同步 。 但 是 ， 
成 员 这 时 并 没有 进入 错误 状态 ， 因 为 它 期 望 
发 现 一 个 拥有 足够 详尽 oplog 的 成 员 ， 然 后 继 
续 同步 oplog， 最 后 回 到 正常 状态 。 


ARBITER 

在 正常 的 操作 中 ， 仲 裁 者 应 该 始终 处 于 
ARBITER 状 态 。 

系统 出 现 问 题 时 会 处 于 下 面 这 些 状 态 。 


e DOWN 
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如 果 一 个 正常 运行 的 成 员 变 得 不 可 达 ， 它 就 
处 于 DONN 状 态 。 注 意 ， 如 果 有 成 员 被 报告 
为 DOWN 状 态 ， 它 有 可 外 Poe 云 行 状 














态 ， 不 可 达 的 原因 可 能 是 网 络 问题 


UNKNOWN 





























成 员 就 无 法 知道 它 处 于 什么 状态 ， 


如 果 一 个 成 员 无 法 到 达 其 他 任何 成 员 ， 其 他 





会 将 其 报 





























告 为 UNKNOWN 状 态 。 通 常 ， 这 表明 这 个 未 知 


状态 的 成 员 挂 控 了 ， 或 者 是 两 个 成 员 之 间 存 


在 网 络 访问 问题 。 


REMOVED 




















F 这 个 状 























当成 员 被 移出 副本 集 时 ， 它 就 处 于 
如 


























集中 ， 它 就 会 回 到 “正常 ”状态 。 











ROLLBACK 























果 被 移出 的 成 员 又 被 重新 添加 到 及 
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本 














如 果 成 员 正 在 进行 数据 回 滚 〈 详 见 10.4 








节 ) ， 它 就 处 于 ROLLBACK 状 态 。 





H 








RN 








结束 时 ， 服 务 器 会 转换 为 RECOVERING 状 


态 ， 然 后 成 为 备份 节点 





e FATAL 


如 果 一 个 成 员 发 生 了 不 可 挽 
FE 常 的 话 ， 它 就 处 于 FATAL 状 

志 来 查 明 为 何 这 个 成 员 
处 于 FATAL 状 态 〈 使 用 "replSet FATAL" 关 











尝试 





] KEI 
态 。 应 该 查看 详细 日 







































































可 的 错误 ， 也 不 





























键 词 在 志 上 执行 grep， 就 可 以 找到 成 员 进 
入 FATAL 状 态 的 时 间 点 ) 。 这 时 ， 通 常 应 该 
重启 服务 器 ， 进 行 重新 同步 或 者 是 从 备份 中 
恢复 。 
10.3 ”选举 
当 一 个 成 员 无 法 到 达 主 节点 时 ， 它 就 会 申请 被 选 
举 为 主 节 点 。 和 希望 被 选举 为 主 节 点 的 成 员 ， 会 向 
它 能 到 达 的 所 有 成 员 发 送 通 知 。 如 果 这 个 成 员 不 
符合 候选 人 要 求 ， 其 他 成 员 可 能 会 知道 相关 原 














有 一 





节点 的 成 员 无 法 到 达 这 个 主 节 点 ) 。 
下 ， 其 他 成 员 不 会 允许 进行 选举 。 


假如 没有 反对 的 理 
进行 选举 投票 。 如 果 这 个 成 员 得 到 六 
多 数 ” 赞 成 票 ， 它 就 
果 达 不 至 








状态 。 如 


























Al: 这 个 成 员 的 数据 落后 于 副本 集 ， 


个 运行 中 的 主 节 点 《那个 力求 被 选举 成 为 主 

















或 者 是 已 经 






































在 这 些 情况 








， 其 他 成 员 就 会 对 这 个 成 员 















































ASE 





“大 











选举 成 功 ， 会 转换 到 主 节点 
“大 多 数 ” 的 要 求 ， 那 么 选举 失 
































状态 ， 








败 ， 它 仍然 处 于 备份 节 
! 请 被 选举 为 主 节点 。 
除非 它 由 于 不 再 满足 "大 多 数 "的 要 求 或 者 


ra) ae 
点 ENN > 








之 后 还 可 以 再 次 

















ETAS 


直 处 于 主 节点 




















KET 
主 节点 退位 。 
































BM BIN E 


段 如 网 络 状况 良好 ， 
运行 ， 那 么 选举 过 程 是 很 快 的 。 
，2 秒 钟 (之 前 讲 过 ， 心 跳 的 间隔 
it 会 有 成 员 发 现 这 个 问题 ， 然 后 会 立即 开始 选 

， 整 个 选举 过 程 只 会 花费 几 





























况 可 和 不 会 这 么 


eS ke 

















跳 会 


情况 下 ， CE 














过 载 导 致 响应 缓慢 ， 都 可 能 
在 最 多 20 秒 之 后 超时 。 











“KEK H 














KERE 


新 配置 也 会 导致 





R 务 器 也 都 在 正常 
如 果 主 节点 不 可 
是 2 秒 ) 之 内 














里 想 : 网 络 问题 ， 


























秒 。 但 是 ， 实 际 





或 者 是 服务 
出发 选举 。 在 这 种 











如 果 选 举 





打 成 平 局 ， 每 个 成 员 都 需要 等 待 30 秒 才能 开始 下 


一 次 选举 。 
举 可 能 会 





10.4 [AR 
根据 





一 个 写 请 求 之 后 挂 了 ， 但 
复制 这 次 操作 ， 那 么 
假如 有 两 个 数据 中 心 ， 





掉 这 次 写 操作 。 




















所 以 ， 如 果 有 太 多 错误 发 生 的 话 ， 选 
花费 几 分 钟 的 时 间 。 




















上 一 节 讲 述 的 选举 过 程 ， 如 果 主 























了 点 执行 ] 


是 备份 节点 还 没 来 得 及 
新 选举 出 来 的 主 节 点 就 会 漏 














Hı 








一 个 











数据 中 心 拥有 一 个 主 节 点 和 一 个 备份 节点 ， 男 一 























个 数据 中 心 扩 





NW 有 三 个 备份 节点 ， 如 图 10-2 所 示 。 











图 10-2 ”一 个 可 能 的 双 数 据 中 心 配置 


如 果 这 两 个 数据 中 心 之 间 出 现 了 网 络 故障 ， 如 图 

10-3 所 示 。 其 中 左边 第 一 个 数据 中 心 最 后 的 操作 

eee 
心 。 



























































图 10-3 ”在 不 同 数据 中 心 之 间 进 行 复制 比 在 单 





一 数据 中 心 内 要 慢 






































右边 的 数据 中 心 仍然 满足 副本 集 “ 大 多 数 ” 的 要 求 
(一 共 5 台 服务 器 ，3 台 即 可 满足 要 求 )。 因 此 ， 
其 中 一 台 服 务 器 会 被 选举 成 为 新 的 主 节点 ， 这 个 
































新 的 主 节点 会 继续 处 理 





4 所 示 。 


后 续 的 写 入 操作 ， 如 图 10- 











中 心 的 写 操作 















































的 操作 撤消 。 拥 有 126 操 作 的 服务 器 会 在 右边 











网 络 恢复 之 后 ， 左 边 数据 中 心 的 服务 器 就 会 从 其 
他 服务 器 开始 同步 126 之 后 的 操作 ， 但 是 无 法 找 
到 这 个 操作 。 这 种 情况 发 生 的 时 候 ，A 和 B 会 进入 
EI (rollback) 过 程 。 回 深 会 将 失败 之 前 未 复 和 


图 10-4 ”右边 数据 中 心 未 能 完成 复制 左边 数据 
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BL 








据 中 心服 务 器 的 oplog 中 寻找 共同 的 操作 点 。 之 后 























会 定位 到 125 操 作 ， 这 是 两 个 数据 中 心 相 匹 配 的 











最 后 一 个 操作 。 图 10-5 显 示 了 oplog 的 情况 。 














B 
四 四 四 


图 10-5 


然 ，A 的 126-128 操 作 被 复制 之 前 ， 
毕 操 作 并 没有 


所 以 这 些 


图 





最 近 操 作 ) 


A 
四 四 四 四 四 四 


中 两 个 成 员 的 oplog 有 冲突 : 很 显 

















AHT, 


HH 现在 B 中 BHAE ZL H 


。A 必 须 先 将 126-128 这 3 个 操作 回 





滚 ， 然 后 才能 重新 进行 同步 


这 时 ， 服 务 
受 这 些 操作 影响 的 文档 写 入 一 个 .bson 文 件 ， 保 存 
在 数据 目录 下 的 rollback 目 录 中 。 如 果 126 是 一 个 
更 新 操作 ， 服 务 器 会 将 被 126 更 新 的 文档 写 入 





collectionName.bson 文 件 。 然 后 会 从 当前 主 节 点 ! 
复制 这 个 文档 。 











器 会 查看 这 些 没有 被 复种 


























下 面 是 
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型 的 











回 深 过 程 产生 的 














1 的 操作 ， 将 









































日 志 : 











Fri Oct 7 06:30:35 [rsSync] replSet syncin 
Fri Oct 7 06:30:35 [rsSync] replSet our la 
06: 30:05:3 


Fri 
Fri 
Fri 
Fri 
Fri 
Fri 


Fri 


Fri 


Fri 


Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 
Fri 





Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
06:30:05:3 

Oct 7 06:30:35 
06:30:31:2 

Oct 7 06:30:35 
-26 seconds 
Oct 7 06:30:35 
06:30:03:4118 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:35 
Oct 7 06:30:36 
Oct 7 06:30:36 


[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 


[rsSync] 
[rsSync] 
[rsSync] 


[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 
[rsSync] 


replset 
replSet 
replSet 
replSet 
replSet 
replSet 


replSet 
replSet 
replSet 


replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 
replSet 


source 
rollba 
ROLLBA 
rollba 
rollba 
info r 


info r 
info r 
rollba 


rollba 
replSe 
rollba 
rollba 
minval 
rollba 
rollba 
rollba 
rollba 
rollba 
rollba 
RECOVE 
syncin 
SECOND 





服务 器 用 





F 始 从 男 一 个 成 员 进 




















行 同步 在 本 例 中 是 














server-1) ， 但 是 发 现 无 法 在 同步 源 中 找到 自己 的 
最 后 一 次 操作 。 这 时 ， 它 就 会 切换 到 回 深 状 态 
("replSet ROLLBACK") 进行 回 滚 。 


第 2 步 ， 服 务 器 在 两 个 oplog 中 找到 一 个 共同 的 
点 ， 是 26 秒 之 前 的 一 个 操作 。 然 后 服务 器 就 会 将 
最 近 26 秒 内 执行 的 操作 从 oplog 中 撤销 。 回 深 完 成 
之 后 ， 服 务 器 就 进入 RECOVERING 状 态 开始 进行 
正常 同步 。 

如 果 要 将 被 回 滚 的 操作 应 用 到 当前 主 节 点 ， 首 先 
使 用 mongorestore 命 令 将 它们 加 载 到 一 个 临时 
集合 : 


$ mongorestore --db stage --collection stu 
> /data/db/rollback/important.stuff.2012-1 







































































































































































现在 应 该 在 shell 中 将 这 些 文 档 与 同步 后 的 集合 进 
行 比较 。 例 如 ， 如 果 有 人 在 被 回 深 的 成 员 上 创建 
了 一 个 “普通 ”索引 ， 而 当前 主 节点 创建 了 一 个 唯 
一 索引 ， 那 么 就 需要 确保 被 回 滚 的 数据 中 没有 重 
复 文 档 ， 如 果 有 的 话 要 去 除 重 复 。 


如 果 希 望 保留 staging 集 合 中 当前 版 本 的 文档 ， 可 
以 将 其 载 入 主 集合 : 


[> staging.stuff.find().forEach(function(do 













































































































































































as prod.stuff.insert(doc); 
. 3) 




















对 于 只 人 允许 插入 的 集合 ， 可 以 直接 将 被 回 滚 的 文 
档 插入 主 集 合 。 但 是 ， 如 果 是 在 集合 上 执行 更 新 
操作 ， 在 合并 回 深 数 据 时 就 要 非常 小 心地 对 待 。 


个 经 常会 被 误 用 的 成 员 配 置 选 项 是 设置 每 个 成 
员 的 投票 数量 。 改 变 成 员 的 投票 数量 通常 不 会 

到 想 要 的 结果 ， 而 且 很 可 能 会 导致 大 量 的 回 滚 操 
作 《〈“ 所 以 上 一 章 的 成 员 属 性 列表 中 没有 介绍 这 个 
选项 ) 。 除 非 做 好 了 定期 处 理 司 滚 的 准备 ， 否则 
不 要 改变 成 员 的 投票 数量 。 


第 11 章 会 讲述 如 何 阻止 回 滚 。 


































































































































































































uf 











如 果 回 深 失 败 























某 些 情况 下 ， 如 果 要 回 深 的 内 容 太 多 ，MongoDB 
可 能 承受 不 了 。 如 果 要 回 滚 的 数据 量 大 于 300 
MB， 或 者 要 回 滚 30 分 钟 以 上 的 操作 ， 回 滚 就 会 
失败 。 对 于 回 滚 失败 的 节点 ， 必 须要 重新 同步 。 


这 种 情况 最 常见 的 原因 是 备份 节点 远 远 落 后 于 主 
节点 ， 而 这 时 主 节点 却 挂 了 。 如 果 其 中 一 个 备份 
节点 成 为 主 节点 ， 这 个 主 节点 与 旧 的 主 节 点 相 
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比 ， 缺 少 很 多 操作 。 为 了 保证 成 员 不 会 在 回 滚 中 
失败 ， 最 好 的 方式 是 保持 备份 节点 的 数据 尽 可 能 
最 新 。 








第 11 章 ”从 应 用 程序 连接 副本 集 


本 章 介 绍 如 何在 应 用 程序 中 与 副本 集 进行 交互 ， 
包括 : 









































。 如 何 连 接 到 副本 集 以 及 故障 转移 的 工作 机 

fills 
。 等待 写 入 复制 ; 
。 将 读 请 求 路 由 到 正确 的 成 员 。 


11.1 客户 端 到 副本 集 的 连接 


从 应 用 程序 的 角度 来 说 ， 使 用 副本 集 与 使 用 单 台 
服务 器 很 像 。 默 认 情 况 下 ， 驱 动 程序 会 连接 到 主 
节点 ， 并 且 将 所 有 请 求 都 路 由 到 主 节点 。 应 用 程 
序 可 以 像 使 用 单 台 服务 器 一 样 进行 读 和 写 ， 副 本 
集会 在 后 台 默 默 处 理 热 备份 。 


连接 副本 集 与 连接 单 台 服 务 器 非常 像 。 在 驱动 程 
序 中 使 用 与 MongoClient 等 价 的 对 象 ， 并 且 提 供 
一 个 希望 连接 到 的 副本 集 种 子 〈seed) 列表 。 种 
子 是 副本 集成 员 。 并 不 需要 将 所 有 成 员 都 列 出 来 
《虽然 可 以 这 么 做 ) : 驱动 程序 连接 到 某 个 种 子 
服务 器 之 后 ， 就 能 够 得 到 其 他 成 员 的 地 址 。 一 
常用 的 连接 字符 串 如 下 所 示 : 
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"mongodb: //server-1:27017,server-2:27017" 
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副本 集 不 能 在 没有 主 节点 的 情况 下 
1 果 有 操作 失败 了 ， 习 
知道 主 
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程序 。 
































常 ， 驱 动 程序 没有 办 法 判 











断 某 次 操作 





的 主 节 点 以 确保 它 同 步 
的 操作 ? 对 这 些 具体 问题 的 处 理 都 取决 于 
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”: 1} 这 个 文档 。 


11.2 等 得 写 入 复制 














前 面 章 节 中 己 经 提 到 |， 
将 写 入 操作 保存 到 副 
入 操作 被 同步 到 了 副 


之 前 ， 我 们 使 
否 成 功 。 也 可 以 使 用 
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驱动 程序 发 出 
后 ， 可 以 查询 主 


果 希 望 不 管 发 生 什么 都 


本 集中 ， 那 么 必须 要 确保 写 


本 集 


jgetLastErrorap 
这 个 命令 
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的 “大 多 数 ”。 
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制 到 备份 节点 。 参 数 " 








殊 的 关键 字 
在 shell! 


可 以 传递 给 
它 如 下 所 示 : 














w" 


求 getLastError 等 待 ， 
都 执行 完了 最 后 的 写 入 操作 。MongoDB 有 一 个 特 


ZIRH 
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命令 检查 写 入 是 
确保 写 入 操作 被 复 


一 直到 给 定数 量 的 成 员 


"w"， 就 是 "majority"。 








> db.runCommand({"getLastError" : 1, "w" : 
{ 
MA “2 s 
"Iastop" : Timestamp(1346790783000, 1) 
“connectionEd 5 
“writtenTo" : [ 
{ "_id" : @, "host" : "server-@" 
{ "_id" : 1 , "host" : "server-1" 
{ "_id" : 3 , "host" : "server-3" 
l 
"wtime" : 76, 
"err" : null, 
'ok" : 1 
} 





注意 ， getLastError 输 出 信息 中 的 新 字 

段 "writtenTo"。 只 有 当 使 用 了 "w" 选 项 并 且 最 
后 的 操作 被 复制 到 多 个 服务 器 时 才 会 有 这 个 字 
段 。 


假设 在 执行 这 个 命令 时 只 有 主 节点 和 一 个 仲裁 者 
节点 可 用 ， 那 么 主 节点 就 无 法 将 这 个 写 操作 复制 
到 副本 集中 的 任何 成 员 。 getLastError 并 不 知 
道 应 该 等 待 多 久 ， 所 以 它 会 一 直 等 待 下 去 。 

此 ， 应 该 始终 为 wtimeout 选 项 设置 个 合理 的 

值 。"wtimeout" 是 getLastError 可 以 使 用 的 另 
一 个 选项 ， 它 的 值 是 命令 的 超时 时 间 ， 如 果 超 过 
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这 个 时 间 还 没有 返 下 














， 就 会 返 下 


























无 法 在 指定 时 i 
员 。 
下 列 代码 的 超时 时 间 是 1 秒 钟 : 


失败 : MongoDB 
司 内 将 写 入 操作 复制 到 "w" 个 成 








> db.runCommand({"getLastError" : 


1, 


"Ww" 














































































































这 个 命令 可 能 会 由 于 多 种 原因 失败 : 其 他 成 员 可 
能 挂 了 ， 可 能 落后 于 主 节点 ， 也 可 能 由 于 网 络 问 
题 不 可 访问 。 如 果 getLastError 超 时 ， 应 用 程 
序 必 须要 对 这 种 情况 作出 处 理 。 注 

意 ，getLastError 超 时 并 不 意味 着 写 操作 失败 
了 ， 仅 仅 表明 写 操作 没 能 在 指定 时 间 内 复制 到 足 








够 多 的 成 员 。 写 操作 仍然 被 复 
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份 节 点 还 来 不 及 跟 
方式 是 定期 调 
为 大 于 1 的 值 。 这 档 
作 一 直 等 待 直到 复制 成 功 。 江 
个 连接 上 的 写 操作 : 
立即 执行 完成 并 返 












































和 i 且 会 尽快 传播 到 其 他 成 员 。 


通常 将 "w" 用 于 控制 写 入 速度 。MongoDB 的 写 入 
速度 “ 太 快 "， 主 节点 上 执行 完 写 入 操作 之 后 ， 备 
FE。 阻止 这 种 行为 的 一 种 常用 
jgetLastError， 将 "w" 参 数 指定 
就 会 强制 这 个 连接 上 的 写 操 
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点 上 没有 的 写 操作 。 为 了 纠正 这 个 问题 
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(getLastError 命 令 的 输 
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用 程序 最 初 
“并且 得 到 了 与 入 成 功 的 确认 信息 ， 
主 节 点 就 拥有 之 前 执行 过 的 写 操 作 (一 
wits ae o 点 ) 。 如 
Rgetiosterrorht, H 程序 就 会 知道 在 操 
MIKER AZN EH RHE ， 应 用 
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HE AA 











"w" 的 其 他 值 











> db.runCommand({"getLastError" 











新 执行 这 个 操 


的 详细 信息 可 以 查看 第 10 章 。 














一 一 个 可 以 传递 给 
的 "w" 参 数 的 值 ，MongoDB 人 允许 
E 意 整数 ， 如 下 所 示 : 





: he 





EEE 
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直到 写 操作 被 复制 到 两 个 
成 员 CF 节点 和 一 个 备份 节 


ya ae 
yr 
TERS ’ 


被 复制 


























"ww" 的 值 包含 了 主 节 点 。 如 果 和 希望 写 操作 
到 n 个 备份 节点 ， 应 该 将 "w" 指 定 

为 n+1 (包括 主 节 点 ) 。 将 "w" 设 置 为 1 相当 于 没 
AIA" w' ' 选 项 ， 因为 MongoDB 只 会 检查 主 节 ， 点 











是 否 成 功 执行 了 写 操作 ，getLastError 始 终 会 
做 这 样 的 检查 。 





使 用 常 


























量 数值 的 次 端 在 于 ， 如 果 副 本 集 的 配置 发 








生 了 变化 ， 就 需要 修改 你 的 应 用 程序 。 
11.3 ”上 自 定义 复制 保证 规则 


写 入 副本 集 的 “大 多 数 “成员 被 认为 是 安全 写 入 。 
然而 ， 有 些 副本 集 可 能 有 更 复杂 的 要 求 :可 能 会 
希望 确保 写 操作 被 复 于 | 到 每 个 数据 中 心中 至 少 二 
台 服 务 器 上 ， 或 者 是 被 复制 到 可 见 节点 的 “大 多 





数 ” 服 务 器 上 。 副 本 集 允 许 创建 自己 的 规则 ， 并 






































且 可 以 传递 给 getLastError， 以 保证 写 操作 被 





复制 到 所 需 的 服务 器 上 。 


























11.3.1 保证 复制 到 每 个 数据 中 心 的 一 台 服 务 器 
E 











KART FA 


个 数据 中 心 内 部 ， 不 同 数据 中 心 之 间 更 











容易 发 生 网 络 故 障 ， 相 对 于 多 个 数据 中 心 同 等 数 








量 的 服务 器 挂 掉 ， 整 个 数据 中 心 挂 掉 的 可 能 性 更 
高 。 因 此 ， 可 能 你 希望 有 一 些 针 对 数据 中 心 的 逻 
辑 来 保证 写 操作 成 功 执行 。 在 确认 成 功 之 前 ， 保 
证 写 操作 被 复制 到 每 一 个 数据 中 心 ， 这 样 ， 万 一 
某 个 数据 中 心 掉 线 了 ， 其 他 每 一 个 数据 中 心 都 有 
一 份 最 新 的 本 地 数据 副本 。 


要 实现 这 种 机 制 ， 首 先 按照 数据 中 心 对 成 员 分 
类 。 可 以 在 副本 集 配置 中 添加 一 个 "tags "字段 : 





































































































> var config = rs.config() 

> config.members[@].tags = {"dc" : "us-eas 
> config.members[1].tags = {"dc" : "us-eas 
> config.members[2].tags = {"dc" : "us-eas 
> config.members[3].tags = {"dc" : "us-eas 
> config.members[4].tags = {"dc" : "us-wes 
> config.members[5].tags = {"dc" : "us-wes 
> config.members[6].tags = {"dc" : "us-wes 

















"tags" 字 段 是 一 个 对 象 ， 每 个 成 员 可 以 拥有 多 个 
标签 。 例 如 ，"us-east" 数 据 中 心 的 服务 器 可 能 
是 "high quality" 服务器， 这样 的 话 ， 可 以 将 
其 "tags" 字 段 配置 为 {"dc": "us-east", 
"quality" : "high"}. 


第 二 步 是 创建 自己 的 规则 ， 可 以 通过 在 副本 集 配 
置 中 创建 "getLastErrorMode" 字 段 实现 。 每 条 


































































































规则 的 形式 都 是 "name" : {"key" : 
number}}. "name" 就 是 规则 的 名 称 ， 名 称 应 该 
能 够 表明 这 条 规则 所 做 的 事情 ， 方 便 客户 端 理 
解 客户 端 在 调用 getLastError 时 才能 够 正确 
选择 自己 需要 的 规则 。 在 本 例 中 ， 将 这 个 规则 命 
名 为 "eachDC"， 或 者 更 抽象 一 点 ， ee 


level safe". 


这 里 的 "key" 字 段 就 是 标签 键 的 值 ， 所 以 在 这 个 
例子 中 是 "dc"。 这 里 的 number 是 需要 遵循 这 条 
规则 的 分 组 的 数量 。 在 本 例 中 ，number 是 2( 因 
为 我 们 希望 写 操作 被 复制 到 "us-east" 和 "us- 

west" 两 个 分 组 中 各 自 至 少 一 台 服 务 

器 ) 。number 的 意思 是 “保证 写 操作 复制 
到 number 个 分 组 ， 每 个 分 组 内 至 少 一 台 服 务 器 
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在 副本 集 配 置 中 添加 "getLastErrorModes" 字 
段 ， 创 建 下 面 的 规则 ， 重 新 执行 配置 : 




































































> config.settings = {} 
> config.settings.getLastErrorModes = [{"e 
> rs.reconfig(config) 




















"getLastErrorModes" 位 于 副本 集 配 置 中 
的 "settings" 子 字段 ， 这 个 字段 下 面包 含 一 些 

















副本 集 级 





别 的 可 选 设置 。 
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E， 可 以 对 写 操作 应 用 这 条 


规则 : 





> db. foo.insert({"x" 





: 1}) 


> db.runCommand({"getLastError" : 1, "w" 
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意 ， 应 用 程序 开发 者 并 不 会 
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"eachDC" 规 则 ， 


知道 到 底 有 哪些 服 











应 用 程序 的 情况 下 任意 修改 具 
的 数据 中 心 ， 或 者 是 更 改 副 
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本 集成 员 数 量 ， 而 
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障 时 不 会 转移 至 


| 隐藏 节点 ， 





到 隐藏 节点 。 你 




















可 能 只 关心 隐 








了 写 请 求 ， 剩 下 的 就 交 给 隐藏 
吧 。 


& 设 我 们 拥有 5 个 成 员 ，host6 到 host4， 其 中 








成 员 自 





我 们 希望 确保 写 操作 被 复 


假 
host4 是 个 隐藏 成 员 。 
制 到 非 隐藏 节点 的 大 多 数 ， 也 就 





是 host6、host1、host2 和 host3 中 的 至 少 三 个 














pas 





首先 为 非 隐藏 节点 








config.members[2].tags 
config.members[3].tags 


> var config = rs.config() 
> config.members[@].tags 
> config.members[1].tags 
> 
> 





不 需要 为 隐藏 节点 (host4) 








= [{"normal" : "A 
= [{"normal" : "B 
= [{"normal" : "C 
= [{"normal" : "D 
设置 标签 。 


现在 ， 为 这 些 服务 器 中 的 大 多 数 添 加 这 条 规则 : 


> rs.reconfig(config) 


> config.settings.getLastErrorModes = [{"v 


















































然后 就 可 以 在 应 用 程序 中 使 用 这 条 规则 了 : 
> db.foo.insert({"x" : 1}) 
> db.runCommand({"getLastError" : 1, "w" : 











命令 会 一 直 等 待 ， 直 到 写 操作 被 复制 到 至 少 三 个 





非 隐 藏 节点 。 








11.3.3 创建 其 他 规则 

















可 以 无 限制 地 创建 各 种 规则 。 记 住 ， 创 建 自 定义 








的 复制 规则 有 两 个 步骤 。 


1. 使 用 键 值 对 设置 成 员 的 ' "tags" 字段 。 这 里 的 
键 用 于 描述 分 组 ， 可 能 会 

有 "data_center"、 "region" sk 

者 "server Quality" 等 键 。 这 里 的 值 表 示 
服务 器 所 属 的 分 组 。 例 如 ， 对 

于 “data_center” 这 个 键 ， 可 以 将 一 些 服 务 
器 标 为 "us-east"， 将 另 一 些 标 为 "us - 
west"， 其 他 的 标 为 "aust"。 


2. 基于 刚刚 创建 的 分 组 创建 规则 。 规 则 总 是 形 
WH{"name" : {"key" : number}}, KZK 
写 操 作 返 回 成 功 之 前 需要 复制 到 至 少 number 
个 分 组 ， 每 个 分 组 内 的 一 合 服务 器 上 。 例 
如 ， 可 以 创建 一 个 {"twoDCs”: 
{"data_center" : 2}} 规 则 ， 意 思 是 说 ， 
在 写 操作 成 功 之 前 ， 需 要 确保 写 操作 被 复制 
到 两 个 数据 中 心 ， 每 个 数据 中 心 内 至 少 一 台 
服务 器 上 。 


然后 就 可 以 在 getLastError 中 使 用 刚刚 创建 的 
规则 了 。 


规则 是 一 种 非常 强大 的 副本 集 配置 方式 ， 虽 然 它 
理解 和 设置 起 来 都 有 些 复杂 。 除 非 有 非常 特殊 的 







































































































































































































































































复制 要 求 ， 否 则 使 用 "w" :"majority" 就 已 经 非 
常安 全 了 。 


11.4 将 读 请 求 发 送 到 备份 节点 


默认 情况 下 ， 了 驱动 程序 会 将 所 有 的 请 求 都 路 由 到 
主 节点 。 这 通常 也 正 是 你 需要 的 ， 但 是 可 以 通过 
设置 驱动 程序 的 读 取 首选 项 (read preferences) 
配置 其 他 选项 。 可 以 在 读 选 项 中 设置 需要 将 查询 
路 由 到 的 服务 器 的 类 型 。 


将 读 请 求 发 送 到 备份 节点 通常 不 是 一 个 好 主意 。 
虽然 在 某 些 特定 情况 下 这 是 有 意义 的 ， 但 是 通常 
应 该 将 全 部 请 求 都 路 由 到 主 节 点 。 如 果 你 正在 考 
虑 将 读 请 求 发 送 到 备份 节点 ， 请 先 从 各 个 方面 好 
好 权衡 之 后 再 做 决定 。 本 节 会 说 明 不 建议 这 么 做 
的 原因 ， 也 会 介绍 需要 这 么 做 的 特定 情况 。 



























































































































































































































































11.41 出 于 一 致 性 考虑 




















对 一 致 性 要 求 非常 高 的 应 用 程序 不 应 该 从 备份 节 
点 读 取 数 据 。 


备份 节点 通常 会 落后 主 节 点 几 毫 秒 ， 但 是 ， 不 能 
保证 一 定 是 这 样 。 有 时 ， 由 于 加 载 问题 、 配 置 错 






























































Hai 
RS 





网 络 故 障 等 原 大 














序 并 


























， 备 份 节点 
节点 几 分 钟 、 几 个 小 时 甚至 几 天 。 客 户 端 驱动 各 
不 知道 备份 节点 的 数据 有 多 
送 给 一 个 远 远 落后 于 主 节点 的 备份 节 


可 能 会 落后 于 主 

















新 ， 所 以 如 果 将 





























端 也 不 会 感觉 到 任何 问题 。 可 
藏 掉 ， 以 避免 客户 端 读 


以 将 备份 


是 这 是 























Me, {6 









































。 如 果 你 的 应 ) 








程序 需要 读 取 最 新 的 











取 数据 。 








pee 














先 插 
样 ， 














JIET m 








入 一 个 文档 ， 然 后 


























再 
点 





自己 
AWE) ’ 那么 不 应 该 
份 节点 〈 除 3 


的 写 操作 《例如 ， 





E 写 操作 像 前 面 那 











使 用 " 





w" 在 返回 





否则 的 话 ， 可 能 会 


> 前 








被 复 和 
出 现 应 | 


il 


所 有 备份 节 

















程序 成 功 执行 











了 一 次 写 操作 ， 却 读 不 到 这 个 值 的 情况 (因为 读 


请 求 被 发 送 给 了 备份 节点 ， 而 之 前 
jj 到 这 个 备份 节点 ) 。 
速度 可 能 会 比 备份 节点 复制 操作 的 速度 要 快 。 


有 被 








为 了 能 











的 写 操 作 还 没 











tt 








客户 端 发 送 请 求 的 


























选项 设置 为 Primary REDE C, RAUD 


是 Primary) 。 





错 。 
能 执 
故障 
者 不 























这 就 是 说 ， 如 果 主 


节点 挂 





如 果 没 有 主 节点 ， 查 询 就 会 出 








了 ， 应 用 程序 就 不 
































行 查 询 了 。 但 
转移 期 间 
\ 接 受 陈 旧 





可 











是 ， 如 果 你 的 应 























程序 需要 在 

















或 者 出 现 网 络 故障 时 正常 运行 ,或 
的 数据 ， 那 么 这 就 是 一 





一 个 可 


j 接受 的 





11.4.2 ”出 于 负载 的 考虑 






































许多 用 户 会 将 读 请 求 发 送 给 备份 节点 ， 以 便 实 现 
分 布 式 负载 。 例 如 ， 如 果 你 的 服务 器 每 秒 只 能 处 
理 10 000 次 查询 ， 而 你 需要 进行 30 000 次 查询 ， 
可 能 就 需要 设置 几 个 备份 节点 ， 并 且 让 它们 分 担 
一 些 数 据 加 载 的 工作 。 但 是 ， 这 种 扩展 方式 非常 
危险 ， 很 容易 导致 系统 意外 过 载 ， 一 旦 出 现 这 种 
问题 ， 很 难 恢复 。 


段 设 你 遇 到 了 上 面 提 到 的 情况 ， 每 秒 30 000 次 读 
请 求 。 你 决定 创建 一 个 拥有 4 个 成 员 的 副本 集 : 
每 个 备份 节点 的 压力 都 在 可 承受 范围 内 ， 整 个 系 
统 也 在 正常 运转 。 


后 来 ， 某 一 个 备份 节点 关 涡 了 。 


现在 剩余 的 每 个 成 员 的 负载 都 是 100%。 如 果 需 要 
恢复 刚刚 般 溃 的 成 员 ， 它 就 需要 从 其 他 成 员 处 复 
制 数据 ， 这 就 会 导致 其 他 成 员 过 载 。 服 务 器 过 载 
经 常 导致 性 能 变 慢 ， 副 本 和 集 性 能 进一步 降低 ， 然 
后 强制 其 他 成 员 承 担 更 多 的 负载 ， 导 致 这 些 成 员 
变 得 更 慢 ， 这 是 一 个 恶性 死 循 环 。 
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过 载 会 导致 副本 集 性 能 降低 ， 然 后 会 导致 剩余 的 

















备份 节点 远 远 落后 于 主 节点 。 突 然 间 ， 你 的 贞 


=, 





本 

















集中 就 有 一 个 成 员 骨 泪 了 ， 还 有 一 个 成 员 远 远 落 




















后 于 主 节 点 ， 导 致 副本 集 的 所 有 成 员 都 过 载 了 
进而 整个 副本 集 都 没有 喘息 的 空间 。 









































如 果 明 确 知道 每 台 服 务 器 能 够 承受 的 负载 ， 你 可 




















能 会 觉得 自己 能 够 更 好 地 应 对 这 种 情况 : 使 用 5 
台 服 务 器 ， 而 不 是 4 台 ， 这 样 如 果 一 台 服 务 器 裔 







































































涡 ， 并 不 会 导致 副本 集 过 载 。 但 是 ， 即 使 你 的 计 












































划 非 常 完 美 《 只 有 预期 数量 的 服务 器 可 能 会 挂 
掉 ) ， 仍 然 需 要 处 理 其 他 服务 器 负载 过 大 的 情 
况 。 
























































13 章 介绍 分 片 相 关 的 知识 。 





11.4.3” 何 时 可 以 从 备份 节点 读 取 数 据 
在 某 些 情况 下 ， 将 读 请 求 发 送 给 备份 节点 是 合 





A 


一 个 更 好 的 选择 是 ， 使 用 分 片 作 分 布 式 负 载 。 第 












































的 。 例 如 ， 你 可 能 希望 应 用 程序 在 主 节点 挂 掉 时 
仍然 能 够 执行 读 操作 而且 你 并 不 在 意 读 到 的 数 
据 是 否 是 最 新 的 ) 。 这 是 最 常见 的 将 读 请 求 发 给 
























































送 备份 节点 的 原因 : 失去 主 节 的 时 ， 应 用 程序 进 








入 只 读 状 态 。 这 种 读 选 项 叫做 主 节点 优先 


(primary preferred) 。 


从 备份 节 
延迟 的 数据 
便 将 请 求 路 
到 副 









































相关 性 


中 心 内 的 应 
延迟 版 本 ) ， 








本 集成 员 的 ping 时 间 ) 。 如 果 你 的 应 上 
从 多 个 数据 中 心中 读 取 到 最 低 延 迟 的 同一 个 
文档 ， 这 是 唯 









































F: 
ea 

















点 读 取 数 据 有 一 个 常见 的 参数 是 获得 低 
居 。 可 以 将 读 选项 设置 为 Nearest， 以 


到 延迟 最 低 的 成 员 ( 根 据 驱动 程序 














REA 





一 的 方法 。 如 果 你 的 文档 与 











更 大 《在 这 个 数据 中 心 内 的 应 用 服务 器 需 
要 得 到 某 些 文档 的 最 低 延 迟 版 本 ， 而 另 一 个 数据 
服务 器 需要 得 到 男 一 o 














MEAN 








的 最 低 






































那 就 应 该 使 用 分 片 。 注 意 ， 如 果 应 





程序 要 求 低 延迟 的 读 和 写 ， TANE 要 使 














分 








副本 集 只 允许 在 主 节 点 上 进行 写 操 作 (不 管 





六 点 在 什么 位 置 ) 。 

















如 果 要 从 一 个 落后 的 备份 节点 读 取 数 据 ， 
牲 一 致 性 。 另 一 方面 ， 如 果 和 希望 写 操 作 返 
























































may 
回 之 前 





























被 复制 到 所 有 副本 集成 员 ， 就 要 牺牲 写 入 





























如 果 应 用 程序 能 够 接受 任何 


























就 可 以 使 用 secondary 或 者 Secondary 





preferred. Secondary RASKE 


发 送 给 备份 节点 。 如 果 没 有 可 用 的 备份 节点 ， 请 











陈旧 程序 的 数据 ， 那 


速度 。 


卖 请 求 











求 就 会 出 错 ， 而 不 是 重新 将 读 请 求 发 送 给 
点 。 对 于 不 在 乎 数据 新 旧 程 度 并 且 希 望 主 


























主 节 
节点 只 











处 理 写 请 求 的 应 用 程序 来 说 ， 这 是 一 种 可 行 的 方 
式 。 如 果 对 于 数据 新 旧 程度 有 要 求 ， 不 建议 使 用 
这 种 方式 。 


Secondary preferred 会 优先 将 读 请 求 路 由 到 
可 用 的 备份 节点 。 如 果 备 份 节点 都 不 可 用 ， 请 求 
就 会 被 发 送 到 主 节点 。 


有 时 ， 读 负载 与 写 负 载 完 全 不 同 : 读 到 的 数据 与 
写 入 的 数据 是 完全 不 同 的 。 为 了 做 离线 处 理 ， 你 
可 能 希望 创建 很 多 索引 ， 但 是 又 不 想 将 这 些 索引 
创建 在 主 节 点 上 。 在 这 种 情况 下 ， 可 以 设置 一 个 
与 主 节点 拥有 不 同 索引 的 备份 节 点 。 如 果 和 希望 以 
这 种 方式 使 用 备份 节点 ， 最 好 是 使 用 驱动 程序 创 
建 一 个 直接 连接 到 目标 备份 节点 的 连接 ， 而 不 是 
连接 到 副本 集 。 


应 该 根据 应 用 程序 的 实际 需要 选择 合适 的 选项 。 
也 可 以 将 多 个 选项 组 合 在 一 起 使 用 : 如 果菜 些 读 
请 求 必 须 从 主 节 点 读 取 数 据 ， 那 就 对 这 些 请 求 使 
Primary 选项 。 如 果 另 一 些 读 请 求 并 不 要 求 数 
据 是 最 新 的 ， 那 么 可 以 对 这 些 读 请 求 使 
jPrimary preferred 选 项 。 如 果 某 些 请 求 对 低 
迟延 的 要 求 大 过 一 致 性 要 求 ， 那 么 可 以 使 
jNearest 选 项 。 
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第 12 章 ”管理 














本 章 介 绍 副 本 集 管理 的 相关 知识 ， 包 括 : 























8 维 








护 独 立 的 成 员 ; 











。 在 多 种 不 同情 况 下 配置 副本 集 ; 
e 获取 oplog 相 关 信息 ， 以 及 调整 oplog 大 小 ; 










































































。 特殊 的 副本 集 配置 


























。 从 主 从 模式 切换 到 副本 集 模式 。 


12.1 





维护 工作 不 能 在 备份 节点 上 进行 











以 单机 模式 启动 成 员 























行 写 操作 ) ， 也 不 能 在 主 节 点 上 进行 。 
































(因为 要 执 
后 面 几 节 











He SI VASA HLH TL (standalone mode) 启动 


服务 器 。 这 是 指 要 重启 成 员 服 务 器 ， 让 它 成 为 一 




















运行 的 服务 器 ， 而 不 再 是 一 个 


副本 集成 员 











(这 只 是 临时 的 〉。 























在 以 单机 模式 启动 服务 器 之 前 ， 先 看 一 下 服务 器 
的 命令 行 参 数 : 








> db. 
{ 


"argv" : [ "mongod", tefi 


serverCmdLineOpts() 


"parsed" : { 


"/var/lib/m 


"replSet": "mySet", 
"port": "27017", 
"dbpath": "/var/lib/db" 
}, 
"ok" : 1 
} 


























如 果 要 对 这 台 服 务 器 进行 维护 ， 可 以 重启 服务 
器 ， 重 启 时 不 使 用 replset 选 项 。 这 样 它 就 会 成 
为 一 个 单机 的 mongod， 可 以 对 其 进行 读 和 与 。 我 
们 不 希望 副本 集中 的 其 他 服务 器 联系 到 这 台 服 务 
器 ， 所 以 可 以 让 它 监听 不 同 的 端口 (这 样 副本 集 
的 其 他 成 员 就 找 不 到 它 了 ) 。 最 后 ， 保 持 dbpath 
的 值 不 变 ， 因 为 重启 后 要 对 这 人 台 服 务 器 的 数据 做 
一 些 操作 。 好 了 ， 我 们 最 终 可 以 用 下 面 这 样 的 参 
数 启 动 服务 器 : 






























































































































































$ mongod --port 30000 --dbpath /var/lib/db 








现在 这 人 台 服 务 器 已 经 在 单机 模式 中 运行 了 ， 监 听 
着 30000 端 口 的 连接 请 求 。 副 本 集中 的 其 他 成 员 
仍然 会 试图 连接 到 它 的 27017 端 口 ， 所 以 会 连接 
失败 ， 其 他 成 员 就 会 以 为 这 台 服 务 器 挂 掉 了 。 




































































当 在 这 台 服 务 器 上 执行 完 维护 工作 之 后 ， 可 以 以 
最 原始 的 参数 重新 启动 它 。 启 动 之 后 ， 它 会 自动 







































































与 副本 集中 的 其 他 成 员 进行 同步 ， 将 维护 期 间 落 
下 的 操作 全 部 复制 过 来 。 


12.2 MARAE 


副本 集 配 置 总 是 以 一 个 文档 的 形式 保存 在 

local.system.replSet 集 合 中 。 副 本 集中 所 有 成 员 的 
这 个 文档 都 是 相同 的 。 绝 对 不 要 使 用 update 更 新 
这 个 文档 ， 应 该 使 用 rs 辅助 函数 或 
者 replSetReconfig 命 令 修 改 副本 集 配 置 。 

















































































































12.2.1 创建 副本 集 














创建 副本 集 的 步骤 很 简单 ， 首 先 启动 所 有 成 员 服 
务 器 ， 然 后 使 用 rs.initiate 命 令 将 配置 文件 传 
递 给 其 中 一 个 成 员 ; 


> var config = 
"id" : setName, 
. "members" : [ 
{"_id" : 0, "host" a host1l}, 
{" id" : 1, "host" : host2}, 
{"_id" : 2, "host" : host3} 













































































- I} 


> rs.initiate (config) 

















MARITAL RArs. initiate, T 
则 MongoDB 会 自动 生成 一 个 针对 单 成 员 副 本 集 的 





























配置 ， 其 中 的 主机 名 可 能 不 是 你 希望 的 。 


只 需要 对 副本 集中 的 一 个 成 员 调 用 rs.initiate 
就 可 以 了 。 收 到 initiate 命 令 的 成 员 会 自动 将 
配置 文件 传递 给 副本 集中 的 其 他 成 员 。 










































































12.2.2 ”修改 副本 集成 员 








向 副本 集中 添加 新 成 员 时 ， 这 个 新 成 员 的 数据 
录 要 么 是 空 的 (在 这 种 情况 下 ， 新 成 员 会 执行 初 
始 化 同步 ) ， 要 么 新 成 员 拥 有 一 份 其 他 成 员 的 数 
据 副 本 。 Ee RTEA 
识 ， 可 以 查看 第 22 章 


连接 到 主 节点 并 且 添 加 新 成 员 : 


























































































































> rs.add("spock:27017") 














也 可 以 以 文档 的 形式 为 新 成 员 指 定 更 复杂 的 配 





























> rs.add({"_id" : 5, "host" : "spock:27017 











可 以 根据 "host "字段 将 成 员 从 副本 集中 移 除 ; 














> rs.remove("spock:27017") 




















可 以 通过 rs .reconfig 修 改 副本 集成 员 的 配置 。 
修改 副本 集成 员 配 置 时 ， 有 几 个 限制 需要 注意 ; 


。 不 能 修改 成 员 的 ” id" 字段; 
。 不 能 将 接收 rs .reconfig 命 令 的 成 员 ¢ 
是 主 节点 ) 的 优先 级 设 为 0; 
° ooo ae RZ 
。 不 能 将 "buildIndexes"” : false 的 成 员 修 
改 为 "buildIndexes" : true. 



























































需要 注意 的 是 ， 可 以 修改 成 员 的 "host" 字 段 。 这 

意味 着 ， 如 果 为 副本 集成 员 指定 了 不 正确 的 主机 
名 (比如 使 用 了 公 网 他 而 不 是 内 网 P〉， 之 后 可 
以 重新 修改 成 员 的 主机 名 。 


下 面 是 一 个 修改 主机 名 的 例子 : 



























































ta 














> var config = rs.config() 

> config.members[@].host = "spock:27017" 
spock: 27017 

> rs.reconfig(config) 











修改 其 他 选项 的 方式 也 是 一 样 的 : 使 
jrs.config 得 到 当前 配置 文件 ， 修 改 配置 文 
件 ， 将 修改 后 的 配置 文件 传递 给 rs.reconfig 就 
















































































可 以 了 。 





12.2.3 创建 比较 大 的 副本 集 








副本 集 最 多 只 能 拥有 12 
员 拥有 投票 权 。 这 是 为 





个 成 员 ， 其 中 只 有 7 个 成 
了 减少 心跳 请 求 的 网 络 流 














te RE AE H 

















求 ) 和 选举 花费 的 时 间 。 











他 所 有 成 员 发 送 心跳 请 
实际 上 ， 副 本 集 还 有 更 


























多 的 限制 ， 如 果 需 要 11 个 以 上 的 备份 节点 ， 可 以 


查看 12.5 节 。 





























如 果 要 创建 7 个 以 上 成 员 的 副本 集 ， 只 有 7 个 成 员 

















可 以 拥有 投票 权 ， 需 要 
置 为 0: 



































将 其 他 成 员 的 投票 数量 设 
































> rs.add({"_id" : 7, "host" : "server-7:27 
这 样 可 以 阻止 这 些 成 员 在 选举 中 投 主动 票 ， 虽 然 
它们 仍然 可 以 投 否决 票 。 

应 该 尽量 避免 修改 成 员 的 投票 数量 。 投 票 可 能 会 





对 选举 和 一 致 性 产生 怪 

















异 的 、 不 直观 的 影响 。 应 








该 只 在 创建 包含 7 个 以 上 成 员 的 副本 集 或 者 是 


望 阻止 自动 故障 转移 


























有 更 多 投票 权 会 使 这 个 





j"votes" 选 项 。 很 多 开发 者 会 误 以 为 让 成 员 扩 

















详 见 12.5.2 节 》 时， 使 

















成 员 更 容易 被 选 为 主 节点 























《实际 上 根本 不 会 ) 。 如 果 和 希望 某 个 成 员 可 以 优 
先 被 选举 为 主 节 点 ， 应 该 使 用 优先 级 〈 详 见 9.6.2 
节 ) 。 
































12.2.4 强制 重新 配置 






































如 果 副 本 集 无 法 再 达到 “大 多 数 ” 要 求 的 话 ， 那 么 
它 就 无 法 选举 出 新 的 主 节 点 ， 这 时 你 可 能 会 希望 
重新 配置 副本 集 。 这 看 起 来 有 点 奇怪 ， 寻 为 通常 
都 是 将 配置 文件 发 送 给 主 节点 。 在 这 种 情况 下 ， 

可 以 在 备份 节点 上 调用 rs.reconfig 强 制 重新 配 
置 (force reconfigure) 副本 集 。 在 shell 中 连接 到 
一 个 备份 节点 ， 使 用 'force" 选 项 执 


5 
Jrs. reconfig 命 命令 : 




































































































































































> rs.reconfig(config, {"force" : true}) 






































强制 重新 配置 与 普通 的 重新 配置 要 遵守 同样 的 规 
则 : 必须 使 有 正确 的 reconfig 选 项 将 有 效 的 、 
格式 完好 的 配置 文件 发 送 给 成 员 。"force" 选 项 
不 允许 无 效 的 配置 ， 而 且 只 允许 将 配置 发 送 给 备 
份 节 点 。 






















































































强制 重新 配置 会 跳 过 大 量 的 数值 n 副本 集 
的 "version" 设 为 一 个 比较 大 的 值 。 可 能 会 见 到 
跳 过 数 千 的 情况 ， 这 很 正常 这 是 为 了 防 












































止 "version" 字 段 冲 突 〈 以 防 不 同 的 网 络 域 中 都 
(lA) 。 


在 进行 重新 配置 





























备份 节点 收 到 新 的 配置 文人 




















员 。 副 本 集 的 








? F ALK 
















































































之后， 就 会 修改 自身 
新 的 配置 发 送 给 副本 集中 的 其 他 
其 他 成 员 收 到 新 的 配置 文件 之 

























































































成 员 的 主机 名 ， 








> 
mE LK 
= 






































了 所 有 


成 员 ， 以 单机 模式 启动 ， 手 动 修改 








发 生变 化 





"OOo ORE RIS 











的 成 员 。 如 果 新 的 配置 文件 修改 














成 员 的 主机 名 ， 应 该 关闭 副本 集 的 每 一 个 








local.system.replset 文 档 ， 然 后 重新 启动 。 
修改 成 员 状 态 
为 进行 维护 或 响应 加 载 ， 有 多 种 方式 可 以 手动 修 


12.3 


改 成 员 的 状态 。 注 意 ， 无 法 强 和 


主 节点 ， 副本 集 做 适当 上 


12.3.1 


除非 对 











可 以 使 
点 : 























| 人 











配置 
































jstepDown 函 数 将 主 节 


把 主 节 点 变 为 备份 节点 


点 降级 为 备份 节 





> rs.stepDown() 














这 个 命令 可 以 证 主 节点 退化 为 备份 节点 ， 并 维 
60 秒 。 如 果 这 段 时 间 内 没有 新 的 主 节 点 被 选举 
来 ， 这 个 节点 就 可 以 要 求 重新 进行 选举 。 如 果 
望 主 节点 退化 为 备份 节点 并 持续 更 长 (或 者 更 
短 ) 的 时 间 ， 可 以 自己 指定 时 间 〈 以 秒 为 单 
位 ) : 
































Er 










































































> rs.stepDown(600) // 16 分 钟 





12.3.2 ”阻止 选举 
































如 果 需 要 对 主 节 点 做 一 些 维护 ， 但 是 不 希望 这 段 
时 间 内 将 其 他 成 员 选 举 为 主 节点 ， 那 么 可 以 在 每 
个 备份 节点 上 执行 freeze 命 令 ， 以 强制 它们 始终 
处 于 备份 节点 状态 : 


> rs.freeze(10000) 


mn 






































ra 

















这 个 命令 也 会 接受 一 个 以 秒表 示 的 时 间 ， 表 示 在 
多 长 时 间 内 保持 备份 节点 状态 。 


佳 护 完 成 之 后 ， 如 果 想 “释放 ”其 他 成 员 ， 可 以 再 
次 执行 freeze 命 令 ， 将 时 间 指 定 为 0 即 可 : 


























ASS 





















































> rs.freeze(@) 




















这 样 ， 其 他 成 员 就 可 以 在 必要 时 申请 被 选举 为 主 
节点 。 




















也 可 以 在 主 节 点 上 执行 rs.freeze(86)， 这 样 可 
以 将 退位 的 主 节点 重新 变 为 主 节 点 。 























12.3.3 ”使 用 维护 模式 

















当 在 副本 集成 员 上 执行 某 个 非常 耗 时 的 操作 时 ， 
这 个 成 员 就 人 进入 维护 模式 (maintenance 

mode) : 强制 成 员 进 入 RECOVERING 状 态 。 有 
时 ， 成 员 会 自动 进入 维护 模式 ， 比 如 在 成 员 上 做 
压缩 时 。 压 缩 开 始 之 后 ， 成 员 会 进 
入 RECOVERING 状 态 ， 这 样 就 不 会 有 读 请 求 发 送 
给 这 个 成 员 。 客 户 端 会 停止 从 这 个 成 员 读 取 数 据 
(如 果 之 前 有 从 这 个 成 员 读 数据 的 话 ) ， 这 个 成 
员 也 不 能 再 作为 复制 源 。 














































































































通过 执行 replSetMaintenanceMode 命 令 


强制 一 个 成 员 进 入 维护 模式 。 如 果 一 个 成 员 远 远 

主 节点 ， 你 不 希望 它 继续 处 理 读 请 求 时 ， 
可 以 强制 让 这 个 成 员 进 入 维护 模式 。 例 如 ， 下 鸡 
这 个 脚本 会 自动 检测 成 员 是 否 落后 于 主 节点 30 秒 





















































































































































以 上 ， 如 果 是 ， 就 强制 将 这 个 成 员 转 入 维护 模 
式 : 














function maybeMaintenanceMode() { 
var local = db.getSisterDB("local"); 





// 如 果 成 员 不 是 备份 节点 《〈 它 可 能 是 主 节 点 

// 或 者 已 经 处 于 维护 状态 ) ， 就 直接 返回 

if (!local.isMaster().secondary) { 
return; 

} 


// 查找 这 个 成 员 最 后 一 次 操作 的 时 间 
var last = local.oplog.rs.find().sort( 
var lastTime = last['ts']['t']; 





























// 如 果 落 后 主 节点 38 秒 以 上 

if (lastTime < (new Date()).getTime()- 
db.adminCommand({"replSetMaintenan 

} 


}3 
将 成 员 从 维护 模式 中 恢复 ， 可 以 使 用 如 下 命令 


> db.adminCommand({"replSetMaintenanceMode 


| 
























































12.4 KRN 





ar 











监控 副本 集 的 状态 非常 重要 : 不 仅 要 监控 是 否 所 
有 成 员 都 可 用 ， 也 要 监控 每 个 成 员 处 于 什么 状 
态 ， 以 及 每 个 成 员 的 数据 新 旧 程度 。 有 多 个 命令 
可 以 用 来 查看 副本 集 相 关 信息 。MMS 〈 详 见 第 21 
章 ) 也 维护 着 一 些 与 复制 相关 的 信息 。 


与 复制 相关 的 故障 通常 都 是 很 短暂 的 : 一 个 服务 
器 刚才 还 连接 不 到 另 一 个 服务 器 ， 但 是 现在 又 可 
以 连 上 了 。 要 查看 这 样 的 问题 ， 最 简单 的 方式 就 
是 查看 日 志 。 确 保 自己 知道 日 志 的 保存 位 置 (而 
且 真 的 被 保 在 下 来 ) ， 确 保全 g 够 访问 到 它们 。 










































































证 






















































































12.4.1 获取 状态 


replSetGetStatus 是 一 个 非常 有 用 的 命令 ， 可 
以 返回 副本 集中 每 个 成 员 的 当前 信息 (这 里 
的 “当前 ”是 从 每 个 成 员 自 身 的 角度 来 说 的 ) 。 这 
个 命令 还 有 一 个 对 应 的 辅助 函数 rs. status: 

























































































> rs.status() 


"set" : "spock", 

"date" : ISODate("2612-16-17T18:17:52Z 
"myState" : 2, 

"syncingTo" : "“server-1:27017", 
"members" : [ 











”id”: 0, 

"name" : "server-1:27017", 
"health" : 1, 

"state" : 1, 

"stateStr" : "PRIMARY", 
"uptime" : 74824, 

"optime" : { "t" : 13504966210 
"optimeDate" : ISODate("2012-1 
"lastHeartbeat" : ISODate("201 
"pingMs" : 3, 


= Td 1 

"name" : "server-2:27017", 
"health" : 1, 

"state" : 2, 

"stateStr" : "SECONDARY", 
"uptime" : 161989, 

"optime" : { "t" : 13503775490 
“optimeDate" : ISODate("2012-1 
"self" : true 


”id”: 2, 

"name" : "server-3:27017", 
"health" : 1, 

"state" : 3, 


"stateStr" : "RECOVERING", 





"uptime" : 24300, 

"optime" : { "t" : 13504114070 
“optimeDate" : ISODate("2012-1 
"lastHeartbeat" : ISODate("201 
"pingMs" : 12, 

"errmsg" : "still syncing, not 














下 面 分 别 介绍 几 个 最 有 用 的 字段 。 


e self 
这 个 字段 只 会 出 现在 执行 rs.status() 函 数 
的 成 员 信息 中 ， 在 本 例 中 是 server-2。 


e stateStr 
用 于 描述 服务 器 状态 的 字符 串 。 关 于 成 员 不 
同 状态 的 描述 ， 可 以 查看 10.2.1 节 。 






























































e uptime 
从 成 员 可 达 一 直到 现在 所 经 历 的 时 间 ， 单 位 
是 秒 。 对 于 "self" 成 员 ， 这 个 值 是 从 成 员 启 
动 一 直到 现在 的 时 间 。 因 此 ，server-2 已 经 启 
动 161 989 秒 了 〈 大 约 45 小 时 ) 。server-1 在 
过 去 的 21 小 时 中 一 直 处 于 可 用 状态 ，server-3 





















































在 过 去 7 小 时 中 一 直 处 于 可 用 状态 。 





e optimeDate 
每 个 成 员 的 oplog 中 最 后 一 个 操作 发 生 的 时 
间 〔 也 就 是 操作 被 同步 过 来 的 时 间 〉。 注 
意 ， 这 里 的 状态 是 每 个 成 员 通 过 心跳 报告 上 
来 的 状态 0 
几 秒 钟 的 偏差 


lastHeartbeat 

当前 服务 器 最 后 一 次 收 到 其 他 成 员 心 跳 的 时 
间 。 如 果 网 络 故 障 或 者 当前 服务 器 比较 繁 
忙 ， 这 个 时 间 可 能 会 是 2 秒 钟 之 前 。 
















































































e pingMs 
心跳 从 当前 服务 器 到 达 某 个 成 员 所 花费 的 平 
均 时 间 ， 可 以 根据 这 个 字段 选择 从 哪个 成 员 
进行 同步 。 




















e errmsg 
成 员 在 心跳 请 求 中 返回 的 状态 信息 。 这 个 字 
段 的 内 容 通常 只 是 一 些 状态 信息 ， 而 不 是 错 
误 信 息 。 例 如 ，server-3 的 "errmsg" 字 段 表 
示 它 正 处 于 初始 化 同步 过 程 中 。 这 里 的 十 六 
进 制 数字 507e9a30:851 是 某 个 操作 对 应 的 时 
间 戳 ，server-3 至 少 要 同步 完 这 个 操作 才能 完 

























































































成 同步 过 程 。 
































有 几 个 字段 的 信息 是 重复 
的 : "state" 与 "stateStr" 都 表示 成 员 的 状态 ， 
只 是 "state" 的 值 是 状态 的 内 部 表示 





法 。 "health" 仅 仅 表示 给 定 的 服务 器 是 否 可 达 








(可 达 是 1， 不 可 达 是 0) ， 而 

从 "state" 和 "stateSstr" 字 段 也 可 以 得 到 这 样 的 
信息 (如 果 服 务 器 不 可 达 ， 它 们 的 值 会 

是 UNKNOWN 或 者 DONN ) 。 类 似 

地 ，"optime" 和 "optimeDate" 的 值 也 是 相同 
的 ， 只 是 表示 方式 不 同 : 一 个 是 用 从 新 纪元 开始 






























































的 毫秒 数 表示 的 ， 男 一 个 用 一 种 更 适合 阅读 的 方 























式 表 示 。 
注意 
员 的 AREAS 出 的 : 





不 准确 或 者 有 些 过 
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12.4.2 Sf 


























， 这 份 报 告 是 以 执行 rs.status() 命 令 的 成 





于 网 络 故障 ， 这 份 报告 可 能 


时 。 











如 果 在 备份 节点 上 运行 rs .status()， 输 出 信息 
Ph 会 有 一 个 名 为 "syncingTo" 的 顶级 字段 ， 用 于 
示 当 前 成 员 正 在 从 哪个 成 员 处 进行 复制 。 如 果 
在 每 个 成 员 上 运行 replSsetGetStatus 命 令 ， 就 





















































可 以 弄 清楚 复制 图 谱 (replication graph) 。 假 设 
server1 表 示 连 接 到 server1 的 数据 库 连 接 ，server2 
表示 连接 到 server2 的 数据 库 连 接 ， 以 此 类 推 ， 然 
后 分 别 在 这 些 连 接 上 执行 下 面 的 命令 : 






























































> serverl.adminCommand({replSetGetStatus: 
server@:27017 
> server2.adminCommand({replSetGetStatus: 
server1:27017 
> server3.adminCommand({replSetGetStatus: 
server1:27017 
> server4.adminCommand({replSetGetStatus: 
server2:27017 











所 以 ，server0 是 server1 的 同步 源 ，serverl 是 
server2 和 server3 的 同步 源 ，server2 是 server4 的 同 
步 源 。 


MongoDB 根 据 ping 时 间 选 择 同步 源 。 一 个 成 员 向 
另 一 个 成 员 发 送 心跳 请 求 ， 就 可 以 知道 心跳 请 求 
所 耗费 的 时 间 。MongoDB 维 护 着 不 同 成 员 间 请 求 
的 平均 花费 时 间 。 选 择 同步 源 时 ， 会 选择 一 个 离 
己 比较 近 而 Heep 己 新 的 成 员 ( 所 以 ,不 
出 现 循环 复制 的 问题 ， 每 个 成 员 要 么 从 主 节 点 
制 ， 要 么 从 数据 比 它 新 的 成 员 处 复制 ) 


此 ， 如 果 在 备份 数据 中 心中 添加 一 个 新 成 员 ， 




















































































































oF ee 



































它 很 可 能 会 从 与 


成 员 


节点 处 复制 《这 相 


自己 同 在 











处 复制 ， 而 不 是 从 位 于 男 一 个 数 扩 
F 可 以 减少 网 络 流量 ) ， 如 图 12- 





1 所 示 。 














个 数据 中 心 内 的 其 他 
居中 心 的 主 





图 12-1 新 的 备份 节 
一 个 数据 中 心 的 
但 是 ， Bay iti 
chaining) 也 有 
| 到 所 有 服务 器 所 花费 和 


Bit 








有 服务 器 者 











=a 






































上 链 (automatic replication 

















位 于 同一 个 数 和 


些 缺 点 : i 











居中 心 内 ， 然后 ， 





点 通 常会 从 与 自己 处 于 同 
其 他 成 员 进 行 复制 


I 链 越 长 ， 将 写 操作 
的 时 间 就 越 长 。 假 设 所 











可 








网 络 速度 异常 ， 新 添加 一 个 成 员 之 后 ，MongoDB 


的 复制 链 妇 





0 图 12-2 所 示 。 





图 12-2 复制 链 越 长 ， 将 数 





器 花费 的 时 间 就 越 长 


。 但 这 种 情况 通常 是 不 可 























个 备份 节 点 都 要 比 它 前 面 











点 。 只 要 出 现 这 种 状况 ， 




















数 rs.syncFrom() ) 命令 
修复 。 














可 以 





J replSetSyncFrom ( ( 或 者 是 它 对 应 的 辅助 








区 改 成 员 的 复制 源 i 





同步 到 全 部 服务 


情况 ， 但 是 并 非 不 可 
可 取 的 : 复制 链 中 的 每 
的 备份 节点 稍微 落后 一 


PR} 
进行 





连接 到 需要 修改 复制 源 的 备份 节点 ， 运 行 这 个 命 

















令 ， 为 其 指定 一 个 复制 源 : 


> secondary.adminCommand({"rep1SetSyncFrom 

















可 能 要 花费 几 秒 钟 的 时 间 才 能 切换 到 新 的 复 币 
源 。 如 果 在 这 个 成 员 上 再 次 执行 rs. status()， 
会 发 现 "syncingTo" 字 上 段 的 值 已 经 变 成 

J "server®:27017". 


现在 ，server4 会 一 直 从 server0 进 行 复 制 ， 直 到 
server0 不 可 用 或 者 远 远 落后 于 其 他 成 员 为 止 。 





= 







































































12.4.3 复制 循环 























如 果 复 制 链 中 出 现 了 环 ， 那 么 就 称 为 发 生 了 复制 
循环 。 例 如 ，A 从 B 处 同步 数据 ，B 从 C 处 同步 数 
据 ，C 从 A 处 同步 数据 ， 这 就 是 一 个 复制 循环 。 
为 复制 循环 中 的 成 员 都 不 可 能 成 为 主 节点 ， 所 以 

这 些 成 员 无 法 复制 新 的 写 操作 ， 就 会 越 来 越 落 
后 。 另 一 方面 ， 如 果 每 个 成 员 都 是 自动 选取 复制 
源 ， 那 么 复制 循环 是 不 可 能 发 生 的 。 


但 是 ， ee A GS 
制 源 时 ， 就 可 能 会 出 现 复制 循环 。 在 手动 修改 成 
员 的 复制 源 时 ， 应 该 子 细 查看 rs .status( ) 的 输 
出 信息 ， 避 免 造 成 复制 循环 。 当 




















































































































jreplSetsyncFrom 为 成 员 指定 一 个 并 不 比 它 领 
先 的 成 员 作为 复制 源 时 ， 系 统 会 给 出 警告 ， 但 是 
仍然 允许 这 么 做 。 









































12.4.4 禁用 复制 链 





当 一 个 备份 节点 从 男 一 个 备份 节点 (而 不 是 主 节 
点 ) 复制 数据 时 ， 就 会 形成 复制 链 。 前 面 说 过 ， 
成 员 会 自动 选择 其 他 成 员 作为 复制 源 。 


可 以 禁用 复制 链 ， 强 制 要 求 每 个 成 员 都 从 主 节 点 
进行 复制 ， 只 需要 将 "allowChaining" 设 置 
为 false 即 可 《如 果 不 指定 这 个 选项 ， 默 认 


是 true) : 






















































































> var config = rs.config() 

> // 如 果 设 置 子 对 象 不 存在 ， 就 自动 创建 一 个 空 的 
> config.settings = config.settings || {} 
> config.settings.allowChaining = false 

> rs.reconfig(config) 






















































































将 allowChaining 设 置 为 false 之 后 ， 所 有 成 员 
都 会 从 主 节点 复制 数据 。 如 果 主 节点 变 得 不 可 
， 那 么 各 个 成 员 就 会 从 其 他 备份 节点 处 复种 
据 。 
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数 





12.4.5 计算 延迟 











跟踪 复制 情况 的 一 个 重要 指标 是 备份 节点 与 主 节 
点 之 间 的 延迟 程度 。 延 迟 Cag) 是 指 备 份 节点 相 
对 于 主 节点 的 落后 程度 ， 是 主 节 点 最 后 一 次 操作 
的 时 间 惟 与 备份 节点 最 后 一 次 操作 的 时 间 惟 的 
Zo 


可 以 使 用 rs.status() 查 看 成 员 的 复制 状态 ， 也 

可 以 通过 在 主 节点 上 执 

行 db.printReplicationInfo()〔 这 个 命令 的 

输出 信息 中 包括 oplog 相 关 信息 ) ， 或 者 在 备份 节 
H 

















































































































点 上 执行 db .printSlaveReplicationInfo() 
快速 得 到 一 份 摘 要 信息 。 注 意 ， 这 两 个 都 是 db 的 
函数 ， 而 不 是 rs 的 。 

















db.printReplicationInfo 的 输出 中 包括 主 节 
点 的 oplog 信 息 : 








> db.printReplicationInfo(); 


configured oplog size: 16.48576MB 
log length start to end: 34secs (0.0 
oplog first event time: Tue Mar 30 
oplog last event time: Tue Mar 30 








now: Tue Mar 30 











上面 的 输出 信息 中 包含 了 oplog 的 大 小 ， 以 及 
oplog 中 包含 的 操作 的 时 间 范 围 。 在 本 例 中 ， 
oplog 的 大 小 大 约 是 10 MB， 而 且 只 包含 大 约 最 近 
30 秒 的 操作 。 


在 实际 的 部 署 中 ，oplog 会 大 得 多 (12.4.6 节 会 
述 如 何 修改 oplog 的 大 小 ) 。 我 们 希望 oplog 的 长 
度 至 少 要 能 够 容纳 一 次 完整 同步 的 所 有 操作 。 这 
样 ， 备 份 节点 就 不 会 在 完成 初始 化 同步 之 前 与 
oplog 脱 节 。 

































































: 第 一 条 操作 与 最 后 一 条 操作 
的 时 间 差 就 是 操作 日 志 的 长 度 。 如 果 服 务 器 才 






































oplog 中 的 第 一 条 操作 会 距离 现在 非常 近 。 在 这 
种 情况 下 ,日 志 长 度 会 比较 小 ， 即 使 oplog 仍 然 
有 可 用 空间 。 对 于 那些 已 经 运行 了 比较 长 的 时 
间 ，oplog 已 经 至 少 被 填 满 一 次 的 服务 器 来 说 ， 
日 志 长 度 是 一 个 非常 有 用 的 度量 指标 。 


在 备份 节点 上 运 
行 db.printSlaveReplicationInfo()， 可 以 

























































































得 到 当前 成 员 的 复制 源 ， 以 及 当前 成 员 相 对 复制 
源 的 落后 程度 等 信息 : 














> db.printSlaveReplicationInfo() ; 
source: server-@:27017 
syncedTo: Tue Mar 3@ 2012 16:44:01 GMT 
= 12secs ago (@hrs) 











这 样 就 可 以 知道 当前 成 员 正 在 从 哪个 成 员 处 复制 
数据 。 在 这 个 例子 中 ， 备 份 节点 比 主 节点 落后 12 
秒 。 


注意 ， 副 本 集成 员 的 延迟 是 相对 于 主 节 点 来 说 
的 ， 而 不 是 表示 需要 多 长 时 间 才 能 更 新 到 最 新 。 
在 一 个 写 操作 非常 少 的 系统 中 ， 有 可 能 会 造成 延 
述 过 大 的 幻觉 。 假 设 一 小 时 执行 一 次 写 操 作 。 刚 
刚 执行 完 这 次 写 操作 之 后 ， 复制 之 前 ， 备 份 节点 
会 落后 于 主 节点 一 小 时 。 但 是 ， Rig 2 ILE EP) 
时 ， 备 份 节点 就 可 以 人 妃 上 主 节点 。 当 监控 低 吞 吐 
量 的 系统 时 ， 这 个 值 可 能 会 造成 迷惑 。 

























































































12.4.6 ”调整 oplog 大 小 


可 以 将 主 节 点 的 oplog 长 度 看 作 维护 工作 的 时 间 
窗 。 如 果 主 节点 的 oplog 长 度 是 一 小 时 ， 那 么 你 就 
只 有 一 小 时 的 时 间 可 以 用 于 修复 各 种 错误 ， 不 然 



































的 话 备 


份 节点 可 外 








得 不 重 3 


让 
Li 


A 
可 




















没有 办 法 在 服务 器 运 
] 以 依次 将 每 台 服 务 器 下 线 ， 
然后 重 


z| 




















新 进行 完全 同步 。 
oplog 能 够 保存 儿 天 或 者 一 个 星 
预 留 足够 的 时 间 ， 月 


音 ， 在 oplog 被 填 满 之 前 很 难 知 道 它 的 长 度 ， 也 
期 间 调 整 oplog 大 小 。 


和 pak 


IST 





新 把 














会 落后 于 主 节 








所 以 ， 





=I 

















H Abs 





它 添加 到 副本 集中 。 
能 成 为 主 节点 的 有 


PAB, BER 
你 通常 可 能 希望 
期 的 数据 ， 从 而 给 
各 种 突 发 状况 。 

















但 
调整 它 的 
记 住 ， 每 


R 务 器 都 应 该 拥有 足够 大 
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以 预 











1. 如 果 当 前 服务 器 是 3 


如 oplog 大 小 ， 


留 足够 的 时 间 
可 以 








图 
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TX 


| FUE TZ 


照 如 


EP. 
下 步骤 。 









































岂 成 员 的 数据 外 





Ae a 


























AANI 














PET 


























> use local 
> // op:"i" 用 





H 











于 查找 最 后 一 





更 


新 到 与 





模式 启动 。 
才 将 oplog 中 的 最 后 一 条 insert 操 作 保存 
中 





条 Insert 操 作 


> var cursor = db.oplog.rs.find({"op" 
> var lastInsert = cursor.sort({"$natu 


> db.tempLastOp.save(lastInsert) 


> 
> // 确保 保存 成 功 ， 这 非常 重要 ! 
> db.tempLastop.findone() 























也 可 以 使 用 最 后 一 项 update 或 者 delete 操 
作 ， 但 是 $ 操 作 符 不 能 插入 到 集合 中 。 


5. 删除 当前 的 oplog: 












































> db.oplog.rs.drop() 








6. 创建 一 个 新 的 oplog: 








> db.createCollection("oplog.rs", {"ca 








7. 将 最 后 一 条 操作 记录 写 回 oplog: 














> var temp = db.tempLastOp.findOne() 
> db.oplog.rs.insert(temp) 

> 

> // 要 确保 插入 成 功 

> db.oplog.rs.findOne() 





























确保 最 后 一 条 操作 记录 成 功 插入 oplog。 如 果 
没有 插入 成 功 ， 把 当前 服务 器 添加 到 副本 集 
之 后 ， 它 会 删除 所 有 数据 ， 然 后 重新 进行 一 






































将 当前 服务 器 作为 副本 集成 员 重 新 启 





























坊 。 注 意 ， 由 于 这 时 它 的 oplog 只 有 一 条 记 



































录 ， 所 以 在 一 段 时 间 内 无 法 知道 oplog 的 真实 
长 度 。 另 外 ， 这 个 服务 器 现在 也 并 不 适合 作 





为 其 他 成 员 的 复制 源 。 


通常 不 应 该 减 小 oplog 的 大 小 : 即使 oplog 可 能 会 
有 几 个 月 那么 长 ， 但 是 通常 总 是 有 足够 的 硬盘 空 
来 保存 oplog，oplog 并 不 会 占用 任何 珍贵 的 资 
源 〈 比 如 CPU 或 RAM) 。 
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12.4.7 ”从 延迟 备份 节点 中 恢复 








假设 有 人 不 小 心 删除 了 一 个 数据 库 ， 幸 好 你 有 一 
个 延迟 备份 节点 。 现 在 ， 需 要 放弃 其 他 成 员 的 数 
据 ， 明 确 将 延迟 备份 节点 指定 为 数据 源 。 有 几 种 















































方法 可 以 使 用 。 























下 面 介绍 最 简单 的 方法 。 


1. 关闭 所 有 其 他 成 员 。 

2. 删除 其 他 成 员 数据 目录 中 的 所 有 数据 。 确 保 
每 个 成 员 〔 除 了 延迟 备份 节点 ) 的 数据 目录 
都 是 空 的 。 
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. 重启 所 有 成 员 ， 然 后 它们 会 自动 从 延迟 备份 


节点 中 复制 数据 。 











这 种 方式 非常 简单 ， 但 是 ， 在 其 他 成 员 完成 初 
化 同步 之 前 ， 副 本 集中 将 只 有 一 个 成 员 可 用 〈 延 
迟 备 份 节点 ) 而 且 这 个 成 员 很 可 能 会 过 载 。 



































ARG 








bb E 
能 更 差 。 


1 


2. 


3 


4. 


. 关闭 所 有 成 员 ， 包 括 延迟 备份 节点 。 
删除 其 他 成 员 《〈 除 了 延迟 备份 节点 ) 的 数 





























重启 所 有 成 员 。 






































12.4.8 创建 索引 


如 果 向 主 节 点 发 送 创建 索引 的 命令 ， 主 节点 会 正 
常 创建 索引 ， 然 后 备份 节点 在 复制 “ 创 





人 
口 


导数 据 量 的 不 同 ， 第 二 种 方式 可 能 更 好 ， 也 可 


=] 


i 





Ko 
. 将 延迟 备份 节点 的 数据 文件 复制 到 其 他 服务 
器 。 


注意 ， 这 样 会 导致 所 有 服务 器 都 与 延迟 备份 节点 
拥有 同样 大 小 的 oplog， 这 可 能 不 是 你 想 要 的 。 












































作 时 也 会 创建 索引 。 这 是 最 简单 的 创建 索引 的 方 


式 ， 

















但 是 创建 索引 是 一 个 需要 消耗 大 量 资源 的 操 























作 ， 可 能 会 导致 成 员 不 可 用 。 如 果 所 有 备份 节点 
同一 时 间 开 始 创建 索引 ， 那 么 几乎 所 有 成 员 


都 在 























引 ’ 
AF 





现在 
功 创建 了 索引 。 






































都 会 不 可 用 ， 一 直到 索引 创建 完成 。 
对 此 ， 可 能 你 会 希望 每 次 只 在 一 个 成 员 上 创建 索 











以 降低 对 应 用 程序 的 影响 。 如 果 要 这 么 做 ， 








Al LAER. 














关闭 一 个 备份 节点 服务 器 。 











将 这 个 服务 器 以 和 


机 模式 启动 。 


























. 在 单机 模式 下 创建 索引 。 








索引 创建 完成 之 后 ， 将 服务 器 作为 副本 集成 


员 重 新 启动 。 














对 副本 集中 的 每 个 备份 节点 重复 第 (1) 步 ~ 第 


(4) 步 。 




















己 的 
式 。 








副本 集 的 每 个 成 员 〈 除 了 主 节 点 ) 都 已 经 成 
现在 你 有 两 个 选择 ， 应 该 根据 自 




















实际 情况 选择 一 个 对 生产 系统 影响 最 小 的 方 


























1. 在 主 节点 上 创建 索引 。 如 果 系 统 会 有 一 段 负 





载 比较 小 的 “空闲 期 ”， 那 会 是 非常 好 的 创建 














索引 的 时 机 。 也 可 以 修改 读 取 首 选项 ， 在 主 
节点 创建 索引 期 间 ， 将 读 操 作 发 送 到 备份 节 

















AEs 

















主 节 点 创建 索引 之 后 ， 














备份 节点 仍然 会 复制 











这 个 操作 ， 但 





是 由 了 





样 的 索引 ， 实 际 上 不 会 再 


. 让 主 节 点 退化 为 备份 节点 ， 对 这 个 服务 器 执 
行 上 面 的 4 步 。 这 时 就 会 发 4 
化 为 备份 节 


主 节 点 退 
新 的 
FE. RIE 
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建 完 
添加 到 副本 集 


意 ， 可 以 使 


























他 成 员 不 同 

















的 索引 。 
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点 : 应 该 将 


果 要 创建 唯 


时 会 非常 有 用 ， 
HERRA, H 
EKRI 














次 创建 索引 。 


这 种 技术 为 某 个 备份 节 


备份 节点 中 已 经 有 了 同 














故障 转移 ， 在 
点 创建 索引 期 间 ， 会 有 
节点 被 选举 为 主 节点 ， 保 证 系统 正常 运 
成 之 后 ， 可 以 重新 将 服务 器 





点 创建 与 





这 种 方式 在 做 离线 数据 处 


但 是 ， 如 果 某 个 备份 节点 的 索 
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否则 ， 


， 备 份 节 

















重新 将 其 


音 册 模式 启动 这 全 
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加 入 副本 集 。 
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12.4.9 在 预算 有 限 的 情况 下 进行 复 于 








b 么 它 水 远 不 能 成 为 主 节 
E 级 设 为 0。 


etn ee 
cant 


He 


角 保 主 节 点 
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如 果 预 算 有 限 ， 不 能 使 用 多 台 高 性 能 服务 器 ， 可 
以 考虑 将 备份 节点 只 用 于 灾难 恢复 ， 这 

节点 不 需要 太 大 的 RAM 和 太 好 的 CPU， 也 不 需要 
太 高 的 磁盘 IO。 这 样 ， 始 终 将 高 性 能 服务 器 作为 
主 节点 ， 比 较 便 宜 的 服务 器 只 用 于 备份 ， 不 处 理 
任何 客户 端 请 求 〈 将 客户 端 配 置 为 将 全 部 读 请 求 
发 送 到 主 节点 ) 。 对 于 这 样 的 备份 节点 ， 应 该 设 
置 这 些 选 项 。 


























































































































"priority" 


人 点 永远 不 会 成 为 主 节 


e "hidden" : true 
将 备份 节点 设 为 隐藏 ， 客 户 端 就 无 法 将 读 请 
求 发 送 给 它 了 。 








e "buildIndexes" : false 

这 个 选项 是 可 选 的 ， 如 果 在 备份 节点 上 创建 
索引 的 话 ， 会 极 大 地 降低 备份 节点 的 性 能 

如 果 不 在 备份 节点 上 创建 索引 ， 那 么 从 备份 
节点 中 恢复 数据 之 后 ， 需 要 重新 创建 索引 。 












































e "votes" : 
在 上 有 两 台 服 务 器 的 情况 下 ， 如 果 将 备份 节 
点 的 投票 数 设 为 0， 那 么 当 备份 节点 挂 掉 之 ， 












































三 台 朋 











后 ， 主 节点 仍然 会 一 直 是 主 节点 ， 不 会 因为 
达 不 到 “大 多 数 ” 的 要 求 而 退位 。 如 果 还 有 第 
有 务 器 (即使 它 是 你 的 应 用 服务 器 〉， 
那么 应 该 在 第 三 台 服 务 器 上 运行 一 个 仲裁 者 






































成 员 ， 而 不 是 将 第 三 台 服 务 器 的 投票 数量 设 
为 0。 


在 没有 足够 的 预算 购买 多 台 高 性 能 服务 器 的 情况 
下 ， 可 以 用 这 样 的 备份 节点 来 保证 系统 和 数据 安 


全 。 























12.4.10 ” 主 节 点 如 何 跟踪 延迟 


























这 个 集合 中 保存 着 所 有 正 从 











司 步 的 成 员 ， 以 及 每 个 成 员 的 














作为 其 他 成 员 的 同步 源 的 成 员 会 维护 一 个 名 为 
local.slaves 的 集合 ， 

当前 成 员 进 行 数据 

数据 新 旧 程 度 。 如 果 使 用 w 参 数 执行 查询 ， 





MongoDB 会 根据 这 




















些 信息 确定 是 否 有 足够 多 、 足 





























够 新 的 备份 节点 可 以 用 来 处 理 查询 。 


local.slaves 集 合 实际 上 是 内 存 中 数据 结构 的 “ 回 
所 以 其 中 的 数据 可 能 会 有 几 秒 钟 的 延 运 : 


E95 
Fas 


















































> db.slaves.find() 
id" : ObjectId("4c1287178e00e93d185856 
s" : "local.oplog.rs", "syncedTo" : { 


€ 


"h 


{ "_id" : ObjectId("4c128730e6e5c3096F40e0 
"ns" : "local.oplog.rs", "syncedTo" 








每 个 服务 器 的 ” id" 字段 非常 重要 : 它 是 所 有 正 
在 从 当前 成 员 进 行 数据 同步 的 服务 器 的 标识 符 。 
连接 到 一 个 成 员 ， 然 后 查询 local.me 集 合 就 可 以 
知道 一 个 成 员 的 标识 符 : 


> db.me.findone() 
{ "_id" : ObjectId("50e6edb517c789e4669521 






































非常 偶然 的 情况 下 ， 由 于 网 络 故 障 ， 可 能 会 发 现 
有 多 台 服 务 器 拥有 相同 的 标识 符 。 在 这 种 情况 
下 ， 只 能 知道 其 中 一 台 服 务 器 相对 于 主 节点 的 新 
旧 程 度 。 所 以 ， 这 可 能 会 导致 应 用 程序 故障 (如 
果 应 用 程序 需要 等 待 特 定数 量 的 服务 器 完成 写 操 
VE) 和 分 片 问题 (数据 迁移 被 复制 到 “大 多 数 ” 备 
份 节点 之 前 ， 无 法 继续 做 数据 迁移 ) 。 如 果 多 台 
服务 器 拥有 相同 的 " id"， 可 以 依次 登录 到 每 台 
服务 器 ， 删 除 local.me 集 合 ， 然 后 重新 启动 
mongod。 启 动 时 ，mongod 会 使 用 新 的 "_id" 重 六 
生成 local.me 集 合 。 


如 果 服 务 器 的 地 址 发 生 了 改变 (假定 "_id" 没 有 
安 ， 但 是 主机 名 变 了 ) ， 可 能 会 在 本 二 所 库 的 
志 中 看 到 键 重复 异常 (duplicate key 
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exception) 。 遇 到 这 种 


GRAY GXH 


青 况 
ses 


之 前 的 例 了 











时 ， 删 除 local.slaves 
简单 ， 
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4 需要 ; 
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除 旧 数据 即 可 ， 











不 需要 处 




















mongod 不 会 清 型 
会 列 出 某 个 几 个 月 
VERMA a (BE 





由 于 


员 ) 。 


本 集 状 态 








Elocal.slaves#24 
之 前 








HENE, 
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冲突 ) 。 


， 所 以 ， 它 


就 不 再 把 该 成 员 作为 同步 
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I 本 集 内 的 成 
FMongoDB 只 是 把 这 个 集合 用 于 报告 复 
， 所 以 这 个 集合 中 的 过 时 数 








外 并 不 会 有 


什么 影响 。 如 果 你 觉得 这 个 集合 中 的 旧 数 据 会 造 


成 困惑 或 者 是 过 于 混乱 ， 可 以 将 整个 集合 删除 。 
的 服务 器 将 当前 
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几 秒 钟 之 后 ， 
复 人 
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如 果 
到 某 
中 有 多 个 文档 。 
复制 请 求 转发 给 
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备份 节点 之 间 形 成 了 复 
个 特定 的 服务 器 在 主 
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这 是 因为 ， 
ETHES 











知道 每 个 备份 节点 的 
ghost syncs) ， 





步 ”( 











AY? 


因为 这 些 请 
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1 成 员 作为 
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居 同 步 ， 只 是 寺 





每 个 备份 节 





给 主 节点 。 








生成 。 
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主 节点 的 loc 
每 个 备 
Hl) De 小 9 这 样 主 节 
步 源 。 这 称 为 
WF 
点 的 同步 源 报 


你 可 能 会 注意 

al.slaves 集 合 

份 节点 都 会 将 
让 点 就 能 够 

“ 影 同 

省 不 会 要 求 进 
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local 数 据 库 只 用 于 维护 复制 相关 信 
息 ， 它 并 不 会 被 复制 。 因 此 ， 如 果 希 望 某 些 数 
据 只 存在 于 特定 的 机 器 上 ， 可 以 将 这 些 数据 保 
存在 local 数 据 库 的 集合 中 。 


12.5 EMNER 


MongoDB 最 初 支 持 一 种 比较 传统 的 主 从 模式 
(master-slave) ， 在 这 种 模式 下 ，MongoDB 不 会 
做 自动 故障 转移 ， 而 且 需 要 明确 声明 主 节点 和 从 
节点 。 有 两 种 情形 应 该 使 用 主 从 模式 而 不 是 副本 
集 : 需要 多 于 11 个 备份 节点 ， 或 者 是 需要 复制 单 
个 数据 库 。 除 非 迫 不 得 已 ， 否 则 都 应 该 使 用 副本 
集 。 副 本 集 更 易 维护 ， 而 且 功 能 齐全 。 主 从 模式 
以 后 会 被 废弃 ， 当 副本 集 能 够 支持 无 限 数据 的 成 
员 时 ， 主 从 模式 很 可 能 会 被 立即 废弃 。 

但 是 ， 有 时 可 能 确实 需要 11 台 以 上 的 备份 节点 
(从 节点 ) ， 或 者 是 需要 复制 单个 数据 库 。 这 些 
情况 下 ， 应 该 使 用 主 从 模式 。 


如 果 要 将 服务 器 设 为 主 节点 ， 可 以 使 用 -- 










































































































































































































































































master 选 项 启动 服务 器 。 对 于 从 节点 ， 有 两 个 可 


















































的 选项 :，--slave 和 --source master. -- 


source 用 于 指定 同步 源 的 主机 名 和 端口 号 。 注 


























意 ， 不 要 使 用 --replSet 选 项 ， 因 为 现在 是 要 设 
































以 这 么 做 : 


置 主 从 模式 ， 而 不 是 副本 外 








aor 





o 





银 如 有 两 台 服 务 器 ，server-86 和 server-1， 可 





$ # server-0 
$ mongod --master 
$ 


$ # server-1 





$ mongod --slave --source server-@:27017 

















这 样 ， 主 从 模式 就 设置 成 功 了 ， 不 需要 其 他 的 设 






























































置 。 在 主 节点 执行 的 写 操 作 ， 会 被 复制 到 从 节点 





主 从 模式 也 可 以 用 于 复制 单个 数据 库 。 可 以 使 
J- -only 选 项 选择 需要 进行 复制 的 数据 库 。 

















$ mongod --slave --source Server-1:27617 - 























驱动 程序 不 会 自动 将 读 请 求 发 送 给 从 节点 。 如 果 









































要 从 从 节点 读 取 数据 ， 需 要 显 式 地 创建 一 个 连 所 
到 从 节点 的 数据 库 连 接 。 











12.5.1 从 主 从 模式 切换 到 副本 集 模式 

















从 主 从 模式 切换 到 副本 集 模式 ， 需 要 停机 一 段 时 
间 ， 步 骤 如 下 。 


1. 停止 系统 的 所 有 写 操作 。 这 非常 重要 ， 因 为 
在 主 从 模式 下 ， 从 节点 并 不 会 维护 一 份 
oplog， 所 以 它 无 法 将 升级 期 间 落下 的 操作 同 

2. 关闭 所 有 的 mongod 服 务 器 。 

3. 使 用 --replSset 选 项 重启 主 节点 ， 不 再 使 

用 --master。 

4. 初始 化 这 个 只 有 一 个 成 员 的 副本 集 ， 这 个 成 
员 会 成 为 副本 集中 的 主 节 点 。 

5. 使 用 - -replSset 和 --fastsync 选 项 启动 从 
节点 。 通 常 ， 如 果 向 副本 集中 添加 一 个 没有 
oplog 的 成 员 ， 这 个 成 员 会 立即 进入 完全 的 初 
始 化 同步 过 程 。fastsync 选 项 用 于 告诉 新 
成 员 不 会 担心 oplog 的 问题 ， 直 接 从 主 节 点 最 

新 的 操作 开始 同步 即 可 。 

6. 使 用 rs.add() 将 之 前 的 从 节点 加 入 副本 

Fes 

7. 对 每 个 从 节点 ， 重 复 第 $ 步 和 第 6 步 。 

8. 当 所 有 从 节点 都 变 为 备份 节点 之 后 ， 就 可 以 
开启 系统 的 写 功能 了 。 


























































































































































































































9. 从 配置 文件 、 命 令 行 别名 和 内 存 中 删 
parapet 这 是 一 个 非常 危险 的 选 
页 ， 它 会 使 成 员 启 动 时 跳 过 一 些 需要 同步 的 
wai. 只 有 在 从 主 从 模式 切换 到 副本 集 时 才 
可 以 使 用 这 个 命令 。 现 在 已 经 切换 完成 了 ， 
不 再 需要 这 个 选项 了 


现在 ， 主 从 模式 已 经 被 切换 为 副本 集 了 。 





















































12.5.2 ”让 副本 集 模仿 主 从 模式 的 行为 



































通常 你 会 希望 主 节点 长 时 间 可 用 ， 因 此 ， 万 一 主 
a 但 是 ， 对 


K 不 允许 进行 自动 故障 转移 
集 的 行为 就 跟 主 从 模式 一 样 了 《对 于 这 种 情况 ， 
建议 使 用 主 从 模式 ， 而 不 是 使 用 副本 集 ) 。 


为 了 实现 这 个 目的 ， 需 要 重新 配置 副本 集 ， 将 所 
有 成 员 ( 除 主 节点 之 外 〉 的 priority 和 votes 设 
为 0。 这 样 一 来 ， 如 果 主 节点 挂 了 ， 不 会 有 任何 
成 员 寻 求 被 选举 为 主 节点 。 另 外 ， 如 果 所 有 备份 
节点 都 挂 了 ， 主 节点 也 仍然 会 一 直 保持 主 节 点 状 
态 ， 不 会 退位 (因为 它 是 整个 系统 中 唯一 一 个 拥 
有 投票 权 的 成 员 ) 















































































































































































































































下 面 的 配置 文件 会 创建 一 个 具有 5 个 成 员 J 副本 
集 ， 其 中 server-0 会 始终 作为 主 节点 ， 其 他 4 个 成 
员 会 始终 作为 备份 节点 : 






































{ 
"id" : "spock", 
"members" : [ 
{"_id" : @, "host" : "server-0:270 
{"_id" : 1, "host" : "server-1:270 
{"_id" : 2, "host" : "server-2:270 
{"_id" : 3, "host" : "server-3:270 
{"_id" : 4, "host" : "server-4:270 
] 
} 
































如 果 主 节点 挂 了 ， 管 理 员 必须 手动 选 出 新 的 主 节 



































如 果 要 手动 将 某 个 备份 节点 提升 为 主 节点 ， 首 先 
要 连接 到 这 个 备份 节点 ， 然 后 执行 强人 I 重新 配 
置 ， 将 它 的 priority 和 votes 修 改 为 1， 同时 将 
先前 的 主 节点 的 priority 和 votes 修 改 为 0。 


列 如 ， 如 果 server-0 挂 了 ， 可 以 连接 到 希望 提升 为 
新 的 主 节点 的 备份 节点 (比如 server-1) ， 然 后 以 
下 面 的 方式 修改 配置 : 

























































































var config = rs.config() 
config.members[1].priority = 1 
config.members[1].votes = 1 
config.members[@].priority = 6 
config.members[@].votes = 6 
rs.reconfig(config, {"force" : true}) 





Ww VY WY MV 


























现在 ， 如 果 运 行 rs.config()， 就 可 以 看 到 新 的 
副本 集 配 置信 息 了 : 


























> rs.config() 





{ 
"_id" : "spock", 
"version" : 3 
"members" : [ 
{"_id" : @, "host" : "server-0:270 
{"_id" : 1, "host" : "server-1:270 
{"_id" : 2, "host" : "server-2:270 
{"_id" : 3, "host" : "server-3:270 
{"_id" : 4, "host" : "server-4:270 
] 
} 





























0 果 新 的 主 节 点 又 挂 了 ， 可 以 重复 上 面 的 步 又 ， 




















第 13 章 ”分 片 




















本 章 介 绍 如 果 扩 展 MongoDB: 





。 分 片 和 集群 组 件 ; 
。 如 何 配置 分 片 









































。 分 片 与 应 用 程序 的 交互 。 








13.1 分 片 简介 


分 片 〈sharding) 是 指 将 数据 拆 分 ， 将 其 分 


放 在 不 同 的 机 器 上 的 过 


程 。 





























有 时 也 用 分 区 
Z 





(partitioning) 来 表示 这 个 概念 。 将 数据 分 散 到 


不 同 的 机 器 上 ， 不 需要 

















可 以 储存 更 多 的 数据 ， 








几乎 所 有 数据 库 软件 都 能 








处 























功能 强大 的 大 型 计算 机 就 
里 更 大 的 负载 。 


进行 手动 分 片 Gmanual 














sharding) 。 应 用 需要 维 


护 : 








与 若干 不 同 数据 


军服 务 








器 的 连接 ， 每 个 连接 还 是 完全 独立 的 。 应 用 程序 

















管理 不 同 服务 器 上 不 同 





适 的 数据 库 上 查询 数据 的 工作 。 这 利 





By 











BA fie, 还 第 管理 





ETE 
































好 地 工作 ， 但 是 非常 难 





节点 或 从 集群 删除 节点 都 很 困 





和 负载 模式 也 不 轻松 。 





De: 











方法 可 以 很 
护 ， 比 如 向 集群 添加 
难 ， 调 整数 据 分 布 





MongoDB 文 持 自动 分 片 Cautosharding) ， 可 以 使 








数据 库 染 构 对 应 用 程序 不 可 见 ， 
， 好 像 始 终 在 使 用 一 个 单 

















管理 。 对 应 用 程序 而 言 
































i HIRIN 








也 可 以 简化 系统 























机 的 MongoDB 服 务 器 一 样 。 F 
自动 处 理 数 据 在 分 片上 的 分 布 ， 也 更 容易 添加 和 





另 一 方面 ，MongoDB 

















不 管 从 开发 





和 度 还 是 运营 


度 来 说 ， 分 片 都 是 最 











困难 最 复杂 
以 用 于 自动 配置 、 
或 使 用 分 片 集群 2 










































































讲 过 的 单机 服务 器 和 副本 集 。 
13.2 ”理解 集群 的 组 件 


MongoDB 的 分 片 机 制 允 许 你 
pr) 的 集群 ， Ta TE 











机 器 (分 








的 MongoDB 配 置 方式 。 有 很 多 组 件 可 
监控 和 数据 转移 。 在 尝试 部 署 














前 ， 你 需要 先 熟悉 前 





而 章节 中 




















含 许多 台 
散在 集群 


创建 一 








中 ， 每 个 分 片 维护 着 
































程序 具 








许多 人 可 


个 数据 集合 
机 服务 器 和 副本 集 相 比 ， 使 


的 子 集 。 与 单 
集群 架构 可 以 使 应 



































更 大 的 数据 处 到 





EAE J 








能 会 混淆 复制 和 分 片 的 概 





念 。 记 住 ， 复 制 是 让 多 台 服 务 器 都 拥有 同样 的 








数据 副本 ， 每 一 台 服 务 器 都 是 
像 ， 而 每 一 个 分 片 都 有 其 他 分 片 拥有 不 同 的 数 
F 集 。 











分 片 的 目标 之 一 是 创建 一 个 扩 
1000 台 机 器 的 集群 ， 整 个 集群 
像 是 一 台 单 机 服务 器 。 为 
库 架 构 的 细节 ， 在 分 片 之 前 要 先 执 和 
一 次 路 由 过 程 。 这 个 路 


















































其 他 服务 器 的 镜 














ASA. 108 








Ce 




















对 应 用 程序 来 说 就 
































了 对 应 用 程序 隐藏 数据 
村 mongos 进 行 
服务 器 维护 着 一 个 “ 



































容 列 表 "”， 指 明了 每 个 分 片 包含 什么 数据 内 容 。 
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应 用 程序 只 需要 连接 到 路 由 服务 器 ， 就 可 以 像 使 

































































有 响应 合并 在 一 起 ， 

















单机 服务 器 一 样 进行 正常 
所 示 。 路 由 服务 器 知道 哪些 数 所 
可 以 将 请 求 转发 给 相应 的 分 片 。 
的 响应 都 会 发 送 给 路 由 月 














的 请 求 了 ， 如 图 1 
ALTOS ot , 





3-1 

















BS, 
返回 给 应 





每 个 分 片 对 i 


求 














路 由 服务 器 将 所 





用 程序 。 对 应 月 





HFE 








序 来 说 ， KA 只 知道 自 己 是 连接 到 了 一 台 单 机 




















e 如 加 








13-2 所 示 。 














图 13-1 使 用 分 片 的 连接 








图 13-2 不 使 用 分 片 的 连接 
13.3 ”快速 建立 一 个 简单 的 集群 


如 前 面 介绍 复制 时 一 样 ， 本 节 会 在 单 台 服务 器 上 
快速 建立 一 个 集群 。 首 先 ， 使 用 --nodb 选 项 启动 















































mongo shell: 





$ mongo --nodb 




















使 用 ShardingTest 类 创建 集群 

















> cluster = new ShardingTest({"shards" : 3 














第 16 章 会 详细 介绍 chunksize 选 项 ， 目 前 来 说 可 
以 简单 将 其 设置 为 1。 


运行 这 个 命令 就 会 创建 一 个 包含 3 个 分 片 
Cmongod 进 程 ) 的 集群 ， 分 别 运 行 在 30000、 
30001、30002 端 口 。 默 认 情 况 
下 ，ShardingTest 会 在 30999 端 口 启 动 mongos。 
接 下 来 就 连接 到 这 个 mongos 开 始 使 用 集群 。 


集群 会 将 日 志 输 出 到 当前 shell 中 ， 所 以 再 打开 
个 shell 用 来 连接 到 集群 的 mongos; 


> db = (new Mongo("1localhost:36999" ) ) .getD 


现在 的 情况 如 图 13-1 所 示 : 客户 端 〈shell ) 连接 
到 了 一 个 mongos。 现 在 就 可 以 将 请 求 发 送 给 

mongos 了 ， 它 会 自动 将 请 求 路 由 到 合适 的 分 片 。 
客户 端 不 需要 知道 分 片 的 任何 信息 ， 比 如 分 片 数 


























































































































































































































量 和 分 片 地 址 。 只 要 要 有 分 片 存 在 ， 就 可 以 向 
mongos 发 送 请 求 ， 它 会 自动 将 请 求 转发 到 合适 的 
分 片上 。 

和 先 插入 一 些 数据 : 


> for (var i=0; i<1000090; i++) { 
db.users.insert({"username" 




































































use 


> db.users.count() 


100000 

















可 以 看 到 ， 与 mongos 进 行 交互 与 使 用 单机 服务 器 
完全 一 样 ， 如 图 13-2 所 示 。 


运行 sh.status() 可 以 看 到 集群 的 状态 : 分 片 摘 
要 信息 ` 数据 库 摘要 信息 ` 集合 摘要 信息 : 




















mr Ni 






































> sh.status() 
--- Sharding Status --- 
sharding version: { "_id" : 1, "versio 
shards: 
{ "_id" : "shardeeee", "host" : "1 
{ "_id" : "shardeeei", "host" : "1 
{ "_id" : "shardeee2", "host" : "1 
databases: 
{ "_id" : "admin", "partitioned" : 
{ "_id" : "test", "partitioned" : 











sh 命令 与 rs 命令 很 像 ， 除 了 它 是 用 于 分 片 的 : rs 








个 全 局 变量 ， 其 中 定义 了 许多 分 片 操作 的 畏 







































































建 的 ) 。 











与 上 而 sh.stats() 的 输出 信息 不 同 ，test 数 据 库 














可 能 有 一 个 不 同 的 主 分 片 (primary shard) 。 


4 











助 函 数 。 可 以 运行 sh.help() 查 看 可 以 使 用 的 辅 
助 函数 。 如 sh.stats() 的 输出 所 示 ， 当 前 拥有 3 
个 分 片 ，2 个 数据 库 〈( 其 中 admin 数 据 库 是 自动 创 











>». 





分 片 是 为 每 个 数据 库 随 机 选择 的 ， 所 有 数据 都 会 
位 于 主 分 片上 。MongoDB 现 在 还 不 能 自动 将 数据 








分 发 到 不 同 的 分 片上 ， 因 为 它 不 知道 你 希望 如 何 
分 发 数据 。 必 须要 明确 指定 ， 对 于 每 一 个 集合 ， 








应 该 如 何 分 发 数据 。 




















主 分 片 与 副本 集中 的 主 节点 不 同 。 








主 分 片 指 的 是 组 成 分 广 的 整个 副本 集 。 而 副本 
































单 台 服 务 器 。 


要 对 一 个 集合 分 片 ， 首 先 要 对 这 个 集合 的 数 
启用 分 片 执行 如 下 命 命令 : 
































集中 的 主 节 点 是 指 副 本 集中 能 够 处 理 写 请 求 的 





ri J 








> sh.enableSharding("test") 














现在 就 可 以 对 test 数 据 库 内 的 集合 进行 分 片 了 。 


对 集合 分 片 时 ， 要 选择 一 个 片 键 (shard key) 。 
片 键 是 集合 的 一 个 键 ， MongoDB 根 据 这 个 键 拆 分 7 
数据 。 例 如 ， 如 果 选 择 基 于 "username" 进 行 分 
片 ，MongoDB 会 根据 不 同 的 用 户 名 进行 分 
片 : "al-steak-sauce" 到 "defcon" 位 于 第 一 
片 ，"defcon1" 到 "howie1998" 位 于 第 二 片 ， 以 
此 类 推 。 选 择 片 键 可 以 认为 是 选择 集合 中 数据 的 
顺序 。 它 与 索引 是 个 相似 的 概念 : 随 着 集合 It 
断 增长 ， 片 键 就 会 成 为 集合 J 最 重要 的 索引 。 只 
有 被 索引 过 的 键 才能 够 作为 片 键 。 


在 启用 分 片 之 前 ， 先 在 希望 作为 片 键 的 键 上 创建 
索引 : 

































































































































































> db.users.ensureIndex({"username" : 1}) 








现在 就 可 以 依据 "username" 对 集合 分 片 了 : 











> sh.shardCollection("test.users", {"usern 









































尽管 我 们 这 里 选择 片 键 时 并 没有 作 太 多 考虑 ， 但 
是 在 实际 中 应 该 仔细 其 酌 。 第 15 章 会 详细 介绍 如 







































































何 选择 片 键 。 
几 分 钟 之 后 再 次 运行 sh.status()， 可 以 看 到 ， 
这 次 的 输出 信息 比较 多 : 
--- Sharding Status --- 
sharding version: { "_id" : 1, "version" 
shards: 
{ "_id" "shardeeee", "host" "loc 
{ "_id" "shardeeei", "host" "loc 
{ "_id" "shardeee2", "host" "loc 
databases: 
{ "id" : "admin", "partitioned" : f 
{ "_id" "test", "partitioned" : tr 
test.users chunks: 
shardeee1 4 
shardeee2 4 
shard6666 5 
{ "username" : { $minKey : 1 } } --> 
on : shard6661 
{ "username" "user1704" } -->> { " 
on : Shard6662 
{ "username" "user240@83" } -->> { 
on : shard6661 
{ "username" "user31126" } -->> { 
on : Shard6662 
{ "username" "user38170" } -->> { 
on : shard6661 
{ "username" "user45213" } -->> { 








on : Shard6662 
{ "username" : "user52257" } -->> { 
on : Shard6661 
{ "username" : "user59300" } -->> { 
on : Shard6662 
{ "username" : "user66344" } -->> { 
on : shardeeee 
{ "username" : "user73388" } -->> { 
on : shardg@eee 
{ "username" : "user80430" } -->> { 
on : Shard6666 
{ "username" : "user87475" } -->> { 
on : Shard6666 
{ "username" : "user94518" } -->> { 
on : Shard6666 























集合 被 分 为 了 多 个 数据 块 ， 每 一 个 数据 块 都 是 集 
合 的 一 个 数据 子 集 。 这 些 是 按照 片 键 的 范围 排列 
的 ({"username" : minValLue} -->> 
"username" : maxVaLue} 指 出 了 每 个 数据 块 
的 数据 范围 ) 。 通 过 查看 输出 信息 中 的 "on”: 
shard 部 分 ， 可 以 发 现 集合 数据 比较 均匀 地 分 布 
在 不 同 分 片上 。 


将 集合 拆 分 为 多 个 数据 块 的 过 程 如 图 13-3 到 图 13- 
5 所 示 。 在 分 片 之 前 ， 集 合 实际 上 是 一 个 单一 的 
数据 块 。 分 片 依据 片 键 将 集合 拆 分 为 多 个 数据 






































































































































块 ， 如 图 13-4 所 示 。 这 块 数据 块 被 分 布 在 集群 中 
的 每 个 分 片上 ， 如 图 13-5 所 示 。 


== 


User0 User999999 


图 13-3 ”在 分 片 之 前 ， 可 以 认为 集合 是 一 个 单 
一 的 数据 块 ， 从 片 键 的 最 小 值 一 直到 片 键 的 最 
大 值 都 位 于 这 个 块 


SminKey || user1704 ||user24083 | | user31126 | | user38170 | | user45213 | | user52257 
User1704 | | user24083 | | user31126 | | user38170 | | user45213 | | user52257 | | user59300 
user59300 | | user66344 | | user73388 | | user80430 | | user87475 | | user94518 
User66344 | | user73388 | | user80430 | | user87475 | | user94518 | | SmaxKey 


图 13-4 ”分 片 依据 片 键 范 围 将 集合 拆 分 为 多 个 
数据 块 














应 






































分 片 0000 
user66344 | | user73388 | | user80430 | | user87475 | | user94518 
user73388 | | user80430 | | user87475 | | user94518 | | $maxkKey 


分 片 0001 


$minKey | | user24083 | | user38170 | | user52257 
user1704 | | user31126 | | user45213 | | user59300 


4) Fr 0002 

user1704 | | user31126} | user45213 | | user59300 
user24083 | | user38170} | user52257 | | user66344 
图 13-$ 数据 块 均衡 地 分 布 在 不 同 分 片上 


注意 ， 数 据 块 列表 开始 的 键 值 和 结束 的 键 
值 ，$minkKey 和 $maxKey。 可 以 将 $minKey 认 为 
是 “ 负 无 穷 ?， 它 比 MongoDB 中 的 任何 值 都 要 小 。 
类 似 地 ， 可 以 将 $maxKey 认 为 是 “ 正 无 穷 ?， 它 比 
MongoDB 中 的 任何 值 都 要 大 。 因 此 ， 经 常会 见 到 
这 两 个 “ 端 值 ” 出 现在 数据 块 范围 中 。 片 键 值 的 范 
围 始终 位 于 $minKey 和 $maxKey 之 间 。 这 些 值 实 
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际 上 是 BSON 类 型 ， 只 是 用 于 内 部 使 用 ， 不 应 该 
被 用 在 应 用 程序 中 。 如 果 和 希望 在 shell 中 使 用 的 
话 ， 可 以 用 MinKey 和 MaxKey 常 量 代 蔡 。 


现在 数据 已 经 分 布 在 多 个 分 片上 了 ， 接 下 来 做 一 
些 碍 询 操作 。 首 先 ， 做 一 个 基于 指定 的 用 户 名 的 
查询 : 































































































> db.users.find({username: "user12345"}) 
{ 
"_id" : ObjectId("50b0451951d30ac57824 
"username" : "user12345", 
"created_at" : ISODate("2012-11-24T03: 





} 


可 以 看 到 ， 查 询 可 以 正常 工作 。 现 在 运 
行 explain() 来 看 看 MongoDB 到 底 是 如 何 处 理 这 
次 查询 的 : 


> db.users.find({username: "user12345"}}). 


{ 























TH 





"clusteredType" : "ParallelSort", 
"shards" : { 
"localhost:30001" : [ 
{ 
"cursor" : "BtreeCursor username_1", 
"nscanned" : 1, 
"nscannedObjects" : 1, 











} 





Nee Ls 


"millis" 
"nYields" 
"nChunkSkips" 
"isMultiKey" 
"indexOnly" 


: 0, 

: 0, 

: 0， 
: false， 
: false， 


"indexBounds" : { 
"username" : [ 


[ 


}s 

"nm 
"nChunkSkips" 
"nYields" 
"nscanned" 
"nscannedobJje 
"millisTotal" 
"millisAvg" 
"numQueries" 
"numShards" 


user12345", 
user12345" 


: 0， 


: 0, 
Bape 


cts" 
: 0， 


1, 


: 0, 


1, 
1 





输出 信息 包含 两 个 部 分 : 








一 个 看 起 来 比较 普通 的 








explain() 输 出 藤 套 在 男 一 个 explain() 输 出 
中 。 外 层 的 explain( ) 输 出 来 自 mongos: 描述 了 
为 了 处 理 这 个 查询 ，miongos 所 做 的 工作 。 内 层 的 
explain() 输 出 来 自 查 询 所 使 用 的 分 片 ， 在 本 例 
中 是 1ocalhost:36661。 


由 于 "username" 是 片 键 ， 所 以 mongos 能 够 直接 
将 查询 发 送 到 正确 的 分 片上 。 作 为 对 比 ， 来 看 一 
下 查询 所 有 数据 的 过 程 : 









































































































































> db.users.find().explain() 


"clusteredType" : "ParallelSort", 
"shards" : { 
"localhost: 30000" : [ 
{ 
"cursor" : "BasicCursor", 


"nscanned" : 37393, 
"nscannedObjects" : 37393, 
"n" : 37393, 

"millis" : 38, 

"nYields" : 0, 
"nChunkSkips" : 6， 
"isMultikey" : false, 
"indexOnly" : false, 
“indexBounds" : { 











} 
l 


"localhost:30001" : [ 
{ 

"cursor" : "BasicCursor", 
"nscanned" : 31303, 
"nscannedObjects" : 31303, 
"n" : 31303, 
"millis" : 37, 
"nYields" : 6， 
"nChunkSkips" : 6， 
"isMultiKey" : false, 
"indexOnly" : false, 
"“indexBounds" : { 


} 
], 


"localhost: 30002" : [ 
{ 

"cursor" : "BasicCursor", 
"nscanned" : 31304, 
"nscannedObjects" : 31304, 
"n" : 31304, 
"millis" : 36, 
"nYields" : 0, 
"nChunkSkips" : 6， 
"isMultikey" : false, 
"indexOnly" : false, 





"indexBounds" : { 


} 
} 
] 


}， 

"n" : 100000, 

"nChunkSkips" : 6， 
"nYields" : 6， 

"nscanned" : 100000, 
"nscannedObjects" : 100000, 
"millisTotal" : 111, 
"millisAvg" : 37, 
"numQueries" : 3, 
"numShards" : 3 


} 














可 以 看 到 ， 这 次 查询 不 得 不 访问 所 有 3 个 分 片 ， 
查询 出 所 有 数据 。 通 常 



































来 说 ， 如 果 没 有 在 查询 中 
晶片 键 ，mongos 就 不 得 不 将 查询 发 送 到 每 个 分 




















使 月 
片 。 





























包含 片 键 的 查询 能 够 直接 被 发 送 到 目标 分 片 或 者 


i=) 
FE 


询 Ctargeted query) 。 有 些 查 询 必 须 被 发 送 到 所 
有 分 片 ， 这 样 的 查询 叫做 分 散 -聚集 查询 
(scatter-gather query) : mongos 将 查询 分 散 到 所 














l 群 分 片 的 一 个 子 集 ， 这 样 的 查询 叫做 定向 查 















































有 分 片上 ， 然 后 将 各 个 分 片 的 查询 结果 聚集 起 
来 。 


完成 这 个 实验 之 后 ， 关 闭 数据 集 。 切 换 回 最 初 的 
shell， 按 几 次 Enter 键 以 回 到 命令 行 。 然 后 运 
行 cluster.stop() 就 可 以 关闭 整个 集群 了 。 

































































> cluster.stop() 



































如 果 不 确定 某 个 操作 的 作用 ， 可 以 使 
jshardingTest 快 速 创 建 一 个 本 地 集群 然后 做 


一 些 尝试 。 
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第 14 章 ”配置 分 片 


上 一 章 中 ， 我 们 在 一 台 机 器 上 创建 了 一 个 “ 集 
TE. AR Se SHE Sb SR, 以 
及 分 片 的 配置 


。 创建 配置 服务 器 、 分 片 、mongos 进 程 。 
。 增加 集群 容量 。 
o 数据 的 存储 和 分 布 。 


14.1 ” 何 时 分 片 


决定 何 时 分 片 是 一 个 值得 权衡 的 问题 。 通 常 不 必 
太 早 分 片 ， 因 为 分 片 不 仅 会 增加 部 署 的 操作 复杂 
度 ， 还 要 求 做 出 设计 决策 ， 而 该 决策 以 后 很 难 再 
改 。 另 外 最 好 也 不 要 在 系统 运行 太 久 之 后 再 分 

片 ， 因 为 在 一 个 过 载 的 系统 上 不 停机 进行 分 片 是 
非常 困难 的 。 


通常 ， 分 片 用 来 : 


° HEJ} JRAM; 

磁盘 空间 ; 

。 减轻 单 台 服务 器 的 负载 ， 
e 处 理 单个 mongod 无 法 承受 的 吞吐 量 。 














P 





































































































































































































@ 

TK 

Se 
ao 


























寻 此 ， 良 好 的 监控 对 于 决定 应 何 时 分 片 是 十 分 重 
要 的 ， 必 须 认 真 对 待 其 中 每 一 项 。 由 于 人 们 往往 
过 于 关注 改进 其 中 一 个 指标 ， 所 以 应 弄 明 白 到 底 
对 一 项 指标 对 自己 的 部 署 最 为 重要 ， 并 提前 做 好 
可 时 分 片 以 及 如 何 分 片 的 计划 。 


随 着 不 断 增加 分 片 数量 ， 系 统 性 能 大 致 会 呈 线 性 
增长 。 但 是 ， 如 果 从 一 个 未 分 片 的 系统 转换 为 只 
有 几 个 分 片 的 系统 ， 性 能 通常 会 有 所 下 降 。 由 于 
迁移 数据 、 维 护 元 数据 、 路 由 等 开销 ， 少 量 分 及 
的 系统 与 未 分 片 的 系统 相 比 ， 通 常 延 公 更 大 ， 否 
吐 量 甚至 可 能 会 更 小 。 因 此 ， 至 少 应 该 创建 3 个 
或 以 上 的 分 片 。 


14.2 ”启动 服务 器 


创建 集群 的 第 一 步 是 启动 所 有 所 需 进 程 。 如 上 章 
所 述 ， 需 建立 mongos 和 分 片 。 第 三 个 组 件 一 一 配 
置 服务 器 也 非常 重要 。 配 置 服务 器 是 普通 的 
mongod 服 务 器 ， 保 存 着 集群 的 配置 信息 : 集群 中 
有 哪些 分 片 、 分 片 的 是 哪些 集合 ， 以 及 数据 块 的 
分 布 。 

















































































































































































































































































































14.2.1 配置 服务 器 





于 集群 的 大 脑 ， 保 存 着 集群 和 分 
片 的 元 数据 ， 即 各 分 片 包含 哪些 数据 的 信息 K 
此 ， 应 该 首先 建立 配置 服务 器 ， 鉴于 它 所 包含 

据 的 极端 重要 性 ， 必 须 启 用 其 日 志 功 能 ， 并 确保 
其 数据 保存 在 非 易 失 性 驱动 器 上 。 每 个 配置 服务 
器 都 应 位 于 单独 的 物理 机 器 上 ， 最 好 是 分 布 在 不 
司 地 理 位 置 的 机 器 上 。 


于 mongos 需 从 配置 服务 器 获取 配置 信息 ， 因 此 配 
置 服务 器 应 先 于 任何 mongos 进 程 启 动 。 配 置 服务 
器 是 独立 的 mongod 进 程 ， 所 以 可 以 像 启 动 “普通 
的 ”mongod 进 程 一 样 启动 配置 服务 器 : 

















配置 服务 器 相当 
R 







































































































































































































































































$ # server-config-1 
$ mongod --configsvr --dbpath /var/lib/mon 
$ 
$ # server-config-2 
$ mongod --configsvr --dbpath /var/lib/mon 
$ 
$ # server-config-3 
$ mongod --configsvr --dbpath /var/lib/mon 




















启动 配置 服务 器 时 ， 不 要 使 用 --replSet 选 项 : 
配置 服务 器 不 是 副本 集成 员 。mongos 会 向 所 有 3 
台 配 置 服务 器 发 送 写 请 求 ， 执 行 一 个 两 步 提交 类 
型 的 操作 ， 以 确保 3 台 服 务 器 拥有 相同 的 数据 ， 

所 以 这 3 台 配 置 服务 器 都 必须 是 可 写 的 在 副本 



























































































































































集中 ， 只 有 主 节 点 可 以 处 理 客户 端的 写 请 求 ) 。 








S 一 个 常见 的 疑问 是 ， 为 什么 要 用 3 
配置 服务 器 ? 因为 我 们 需要 考虑 不 时 之 需 。 
是 ， 也 不 需要 过 多 的 配置 服务 器 ， HAME 
有 务 器 上 的 确认 动作 是 比较 耗 时 的 。 另 外 ， 如 
有 服务 器 宕 机 了 ， 集 群 元 数据 就 会 变 成 只 读 
姑 此 ，3 台 就 足够 了 ， 既 可 以 应 对 不 时 之 
需 ， 又 无 需 承受 服务 器 过 多 带 来 的 缺点 。 这 个 
数字 未 来 可 能 会 发 生变 化 。 


--configsvr 选 项 指定 mongod 为 新 的 配置 服务 
器 。 该 选项 并 非 必 选 项 ， 因 为 它 所 做 的 不 过 是 将 
mongod 的 默认 监听 端口 改 为 27019， 并 把 默认 的 
数据 目录 改 为 /data/configdb 而 已 〈 可 使 用 - -port 
和 --dbpath 选 项 修改 这 两 项 配置 ) 。 


日 建议 使 用 - aoo 寻 为 它 比较 直 白 
地 说 明了 这 些 配置 服务 器 的 用 途 。 当 然 ， 如 果 不 
j 它 启动 配置 服务 器 也 没 问 题 。 


配置 服务 器 并 不 需要 太 多 的 空间 和 资源 。 配 置 服 
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务 器 的 1KB 空 间 约 等 于 200 MB 真实 数据 ， 它 保存 


























的 只 是 数据 的 分 布 表 。 由 于 配置 服务 器 并 不 需要 
































太 多 的 资源 ， 因 此 可 将 其 部 署 在 运行 着 其 他 程序 








器 ， 或 mongos 进 程 
如 果 所 有 的 配置 月 





的 服务 器 上 。 









































SS Sad 




















的 机 器 上 ， 如 应 用 服务 器 、 分 片 的 mongod 服 务 




















务 器 都 不 可 用 ， 就 要 对 所 有 分 





片 做 数据 分 析 ， 以 便 知道 每 个 分 片 保存 的 是 什么 
样 的 数据 。 这 是 可 行 的 ， 但 速度 较 慢 ， 且 令 人 大 
烦 。 比 较 好 的 方式 是 经 常 对 配置 服务 器 做 数据 备 









































份 。 应 常 在 执行 集群 维护 操作 之 前 备份 配置 服务 





器 的 数据 。 


14.2.2 ”mongos 进 程 





三 个 配置 服务 器 均 处 于 运行 状态 后 ， 局 动 一 个 
mongos 进 程 供应 用 程序 连接 。mongos 进 程 需 知道 





















































配置 服务 器 的 地 址 ， 所 以 必须 使 














选项 启动 mongos: 





j--configdb 





> -f /var/1lib/mongos. conf 





$ mongos --configdb config-1:27019, config- 








默认 情况 下 ，mongos 运 行 在 27017 端 口 。 注 意 ， 






































并 不 需要 指定 数据 目录 (mongos 自 

















自身 并 不 保存 数 








据 ， 它 会 在 启动 时 从 配置 服务 器 加 载 集 群 数 


























据 ) 。 确 保 正 确 设 置 了 logpath， 以 便 将 mongos 
志保 存 到 安全 的 地 方 。 


可 启动 任意 数量 的 mongos 进 程 。 通 常 的 设置 是 每 
个 应 用 程序 服务 器 使 用 一 个 mongos 进 程 ( 与 应 用 
服务 器 运行 在 同一 台 机 器 上 ) 。 


每 个 mongos 进 程 必须 按照 列表 顺序 ， 使 用 相同 日 
配置 服务 器 列表 。 
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14.2.3 ”将 副本 集 转 换 为 分 片 

















终于 可 以 添加 分 片 了 。 有 两 种 可 能 性 ， 已 经 有 ] 
一 个 副本 集 ， 建立 集群 。 下 例假 设 
我 们 已 经 拥有 了 一 个 副本 集 。 如 果 是 从 零 开始 的 
话 ， 可 先 初始 化 一 个 空 的 副本 ， 然 后 按照 本 例 
的 步骤 进行 后 续 操 作 。 


如 已经 有 一 个 使 用 中 的 副本 集 ， 该 副本 集会 成 为 
第 一 个 分 片 。 为 了 将 副本 和 集 转换 为 分 片 ， 需 告知 
mongos 副 本 集 名 称 和 副本 集成 员 列 表 。 












































































































































例如 ， 如 果 在 server-1、server-2、server-3、 
server-4、server-5 上 有 一 个 名 为 spock 的 副本 集 ， 
可 连接 到 mongos 并 运行 : 














> sh.addShard("spock/server-1:27017, server 


"added" : "spock/server-1:27017, server 
"ok" : true 














可 在 参数 中 指定 副本 集 的 所 有 成 员 ， 但 并 非 一 定 
要 这 样 做 。mongos 能 够 自动 检测 到 没有 包含 在 副 
本 集成 员 表 中 的 成 员 。 如 运行 sh.status()， 可 
发 现 MongoDB 已 经 找到 了 其 他 的 副本 集成 

员 : "spock/server- 1:27017,server- 
2:27017,server-4:27017,server- 
3:27017,server-5:27017". 


副本 集 名 称 spock 被 用 作 分 片 名 称 。 如 之 后 希望 移 
除 这 个 分 片 或 是 向 这 个 分 片 迁移 数据 ， 可 使 

spock 来 标识 这 个 分 片 。 这 比 使 用 特定 的 服务 
a re aa ee 
是 不 断 改 变 的 。 


将 副本 集 作 为 分 片 添加 到 集群 后 ， 就 可 以 将 应 用 
程序 设置 从 连接 到 副本 集 改 为 连接 到 mongos 。 ie 
加 分 片 后 ，mongos 会 将 副本 集 内 的 所 有 数据 库 注 
册 为 分 片 的 数据 库 ， 因 此 所 有 查询 都 会 被 发 送 到 
新 的 分 片上 。 与 客户 端 库 一 样 ，mongos 会 自动 处 
理应 用 故障 ， 将 错误 返回 给 客户 端 。 


























































































































































































































































































































在 开发 环境 中 可 测试 一 下 让 分 片 的 主 节点 挂 掉 ， 
以 确保 应 用 程序 能 够 正确 处 理 mongos 返 回 的 错 
误 。 “错误 应 与 直接 对 话 主 节点 返回 的 错误 相 
同 。) 















































Reith RE Wb ZUR Pn BE 
将 所 有 请 求 发 送 到 mongos， 而 不 是 副本 集 。 如 
果 客 户 端 仍然 把 请 求 直接 发 送 给 副本 集 〈 而 不 
是 通过 mongos) 的 话 ， 分 片 是 无 法 正常 工作 
的 。 添 加 分 片 后 ， 应 立即 将 客户 端 配 置 为 把 请 
求 发 送 给 mongos， 同 时 配置 防火 墙 规则 ， 以 确 
保 客 户 端 不 能 直接 将 请 求 发 送 给 分 片 。 


有 一 个 --shardsvr 选 项 ， 与 前 面 介绍 过 的 -- 

configsvr 选 项 类 似 ， 它 也 没什么 实用 性 (只 是 
将 默认 端口 改 为 27018) ， 但 建议 在 操作 中 选择 
该 选项 。 


也 可 以 创建 单 mongod 服 务 器 的 分 片 〈 而 不 是 副本 
集 分 片 ) ， 但 不 建议 在 生产 中 使 用 〈 上 一 章 中 的 
ShardingTest 是 这 么 做 的 ) 。 直 接 
在 addshard() 中 指定 单个 nongod 的 主机 名 和 端 

































































































































































































































































， 就 可 以 将 其 








添加 为 分 片 了 : 








> sh.addShard("some-server: 27017") 








5 
1 











shard0001， 依 次 类 推 。 
Æ 


AIN 


而 不 是 直接 将 间 















































服务 器 分 片 默认 会 被 命名 为 shard0000、 
如 打算 以 后 切换 为 训 
， 应 先 创建 一 个 单 成 员 各 
服务 器 添加 为 
副本 集 需 停机 操作 ( 详 见 


I 本 
I 本 集 再 添加 为 分 片 ， 
分 片 。 将 单一 服 
10.3 



































务 器 分 片 转换 为 
节 ) 。 


BR 








14.2.4 增加 集群 


Hal 











可 通过 增加 


rH 





分 片 来 增加 集群 容 





4 














的 、 空 的 分 片 ，5 
集 的 名 字 与 ] 


HJY 








te 
其 他 分 片 不 同 。 

















BA 完成 初始 化 并 














拥有 一 个 主 节 点 后 ， 可 加 




















午 mongos 上 运 








行 addshard() 命 令 ， 将 





集 作为 分 片 添加 到 


=, 
































I 本 集 的 名 称 和 主机 名 作 














集群 中 ， 在 参数 中 指定 有 
为 种 子 。 


如 有 多 个 现存 的 和 























| 本 集 没有 作为 分 片 ， 只 要 它们 








没有 同名 的 数据 库 ， 曾 
添加 到 集群 中 。 例 如 ， 
本 集 、 一 个 calendar 数 ] 


mail, tel, music24 


h 














可 将 它们 作为 新 分 


据 库 
居 库 的 副本 集 ， 可 将 每 个 曲 


片 全 部 
0 有 一 个 blog 数 据 库 的 副 
的 副本 集 ， 以 及 一 个 
本 
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集 作 为 一 个 分 片 添加 到 集群 中 ， 这 样 就 可 以 得 到 
个 拥有 三 个 分 片 、 五 个 数据 库 的 集群 。 但 是 ， 
如 果 还 有 一 个 数据 库 名 称 为 tel 的 副本 集 ， 那 么 
mongos 会 拒绝 将 这 个 副本 集 作 为 分 片 添加 到 集群 


A, 










































































14.2.5 数据 分 片 


除非 明确 指定 规则 ， 和 否则 MongoDB 不 会 自动 对 数 
据 进 行 拆 分 。 如 有 必要 ， 必 须 明 确 告知 数据 库 和 


EA 


NA o 





























假设 我 们 希望 对 music 数 据 库 中 的 artists 集 合 按 
照 name 键 进行 分 片 。 首 先 ， 对 music 数 据 居 


E Ja H 
分 片 























Cad 


MN 

















> db.enableSharding("music") 











对 数据 库 分 片 是 对 集合 分 片 的 先决 条 件 。 


对 数据 库 启用 分 片 后 ， 就 可 以 使 
jshardCollection( ) 命 令 对 集合 分 片 了 : 
























































> sh.shardCollection("music.artists", {"na 





























现在 ， 集 合 会 按照 name 键 进行 分 片 。 如 果 是 对 已 














存在 的 集合 进行 








引 ， 否 则 shard 














出 现 了 错误 ， 








Collection() ik 
就 先 创 建 索 引 (mongos 会 


的 索引 作为 错误 消息 的 一 部 分 返 


shardCollection() 命 令 。 


如 要 进行 分 片 的 集合 还 不 存在 ，mongos 会 自动 在 
片 键 上 创建 索引 。 


shardCollection() MSS: 
AHE, i AEMongoDBit K BHR Eo AT 
令 成 功 执行 后 ，MongoDB 会 均衡 地 将 集合 数据 分 
散 到 集群 的 分 片上 。 这 个 过 程 不 是 瞬间 完成 的 ， 





























对 于 比较 大 的 集合 ， 可 能 会 


成 。 


14.3 MongoDB 如 何 i 
每 个 mongos 都 必须 能 够 根据 给 

















的 存放 位 置 。 理论 上 来 说 ，MongoDB 有 














每 个 文档 的 位 置 








， 但 当 集 合 中 




















文档 的 时 候 ， 























定 片 键 特 定 范围 内 的 文档 纪 








于 个 分 片 E 









































分 片 ， 那 么 name 键 上 必须 有 索 
返回 错误 。 如 果 
会 建议 创建 






































HEK o 





花费 几 个 小 时 才 


追踪 集群 数据 


定 的 片 键 找到 文档 
E 够 追踪 到 
包含 成 百 上 干 万 个 
i 会 变 得 难以 操作 。 
AE (chunk) ， 每 个 块 

















KIE, 











B]) ， 然 后 重 试 





等 集合 拆 分 为 多 个 


bb 


用 元 


























上 ， 所 以 MongoDB 用 一 个 比较 小 的 表 
就 能 够 维护 块 跟 分 片 的 映射 。 








例如 ， 如 用 户 集 合 的 片 键 是 {"age”: 1}， 其 中 
某 个 块 可 能 是 由 age 值 为 3~17 的 文档 组 成 的 。 如 
果 mongos 得 到 一 个 {"age"” : 5} 的 查询 请 求 ， 它 
就 可 以 将 查询 路 由 到 age 值 为 3~17 的 块 所 在 的 分 
片 。 
































进行 写 操作 时 ， 块 内 的 文档 数量 和 大 小 可 能 会 发 
生 改变 。 插 入 文档 可 使 块 包 含 更 多 的 文档 ， 删 除 
文档 则 会 减少 块 内 文档 的 数量 。 如 果 我 们 针对 儿 
童 和 中 小 学 生 制 作 游 戏 ， 那 么 这 个 age 值 为 3~17 
的 块 可 能 会 变 得 越 来 越 大 。 几 乎 所 有 的 用 户 都 会 
被 包含 在 这 个 块 内 ， 且 在 同一 分 片上 。 这 就 违背 
了 我 们 分 布 式 存放 数据 的 初衷 。 因 此 ， 当 一 个 块 
增长 到 特定 大 小 时 ，MongoDB 会 自动 将 其 拆 分 为 
两 个 较 小 的 块 。 在 本 例 中 ， 该 块 可 能 会 被 拆 分 为 
一 人 age 值 为 3~11 的 块 和 个 age 值 为 12~17 的 
块 。 注 意 ， 这 两 个 小 块 包 含 了 之 前 大 块 的 所 有 文 
i 这 些小 块 变 大 后 ， 会 被 
续 拆 分 为 更 小 的 块 ， 直 到 包含 age 的 全 部 域 


块 与 块 之 间 的 age 值 范围 不 能 有 交集 ， 如 3~15 和 
12~17。 如 果 存 在 交集 的 话 ， 那 么 MongoDB 为 了 
查询 处 于 交集 中 的 age 值 (如 14) 时 ， 则 需 分 别 
查找 这 两 个 块 。 只 在 一 个 块 中 进行 查找 效率 会 更 
高 ， 尤 其 是 在 块 分 散在 集群 中 时 。 
































































































































































































































一 个 文档 ， 属 于 且 只 属于 
可 以 使 用 数组 字段 作为 片 
数组 创建 多 个 索引 条 目 。 


























age 字段 值 是 [5，26，83]， 该 文档 就 会 出 现在 














三 个 不 同 的 块 中 。 





一个 常见 的 
据 保存 在 磁盘 的 同一 片 














个 块 。 这 意味 着 ， 不 
键 ， 因 为 MongoDB 会 为 
例如 ， 如 某 个 文档 的 











误解 是 同一 个 块 内 的 数 
区 域 。 这 是 不 正确 的 ， 














块 并 不 影响 mongod 保 存 集合 数据 的 方式 。 


14.3.1 块 范 














可 使 用 块 包含 的 文档 范围 










































































来 描述 块 。 新 分 片 的 集 


合 起 初 只 有 一 个 块 ， 所 有 文档 都 位 于 这 个 块 中 。 
此 块 的 范围 是 负 无 穷 到 正 无 穷 ， 在 shell 中 
j$minKey 和 $maxKey 表 示 。 


随 着 块 的 增长 ，MongoDB 会 自动 将 其 分 成 两 个 
块 ， 























范围 分 别 是 负 无 穷 到 
































的 值 相同 ， 范 围 较 小 的 块 包 含 比 小 的 所 有 文档 
(但 不 包含 值 )， 范 围 较 大 的 块 包 含 从 一 直至 


和 到 下 无穷。 两 个 块 中 

















IE 


无 穷 的 所 有 文档 〈 包 含 值 ) 。 




















一 个 例子 来 更 直观 地 说 明 : 假如 我 们 按照 之 前 
提 到 的 "age" 字 段 进 行 分 片 。 所 有 "age" 值 为 
3~17 的 文档 都 包含 在 一 个 块 中 : 3 < age < 
17。 该 块 被 拆 分 后 ， 我 们 得 到 了 两 个 较 小 的 块 ， 
其 中 一 个 范围 是 3 < age < 12， 另 一 个 范围 是 
12 < age < 17。 这 里 的 12 就 叫做 拆 分 点 (split 
point) 。 





















































块 信息 保存 在 config.chunks 集 合 中 。 查 看 集合 内 



































容 ， 会 发 现 其 中 的 文档 如 下 简洁 起 见 ， 这 里 忽 
略 了 二 些 字 段 ) : 
> db.chunks.find(criteria, {"min" : 1, "ma 
{ 
"_id" : "test.users-age -100.0", 
"min" : {"age" : -100}, 
"max" : {"age" : 23} 
} 
{ 
"_id" : "test.users-age 23.0", 
"min" : {"age" : 23}, 
"max" : {"age" : 100} 
} 
{ 


"_id" : "test.users-age 100.0", 
"min" : {"age" : 100}, 
"max" : {"age" : 1000} 

















基于 以 上 config.chunks 文 档 ， 不 同文 档 在 块 中 的 分 
布 情况 如 下 例 所 示 : 


e {"_id" : 123, "age" : 50} 


该 文档 位 于 第 二 个 块 中 ， 因 为 第 二 个 块 包 
含 age 值 为 23~100 的 所 有 文档 。 
e {"_id" : 456, "age" : 100} 
该 文档 位 于 第 三 个 块 中 ， 因 为 较 小 的 边界 值 
是 包含 在 块 中 的 。 第 二 个 块 包含 了 age 值 小 
于 100 的 所 有 文档 ， 但 不 包含 等 于 100 的 文 
档 。 
e {"_id" : 789, "age" : -101} 


该 文档 不 位 于 上 面 所 示 的 这 些 块 中 ， 而 是 位 
于 一 个 比 第 一 个 块 范围 更 小 的 块 中 。 
可 使 用 复合 片 键 ， 工 作 方 式 与 使 用 复合 索引 进行 
排序 一 样 。 假 如 在 {"username" : 1, "age" : 
1} 上 有 一 个 片 键 ， 那 么 可 能 会 存在 如 下 块 范围 


{ 

















oa 
























































































































































"id" : "test.users-username_MinKkeyage 





min" : { 
"username" : { "$minKey" : 1 }, 
"age" : { "$minkKey" : 1 } 


}, 
"max" : { 
"username" : "user107487", 
"age" : 73 
} 
"id" : "test.users-username_\"user107 
"min" : { 
"username" : "user107487", 
"age" : 73 
}s 
max" : { 
"username" : "user114978", 
"age" : 119 
} 
"id" : "test.users-username_\"user114 
"min" : { 
"username" : "user114978", 
"age" : 119 
Jo 
"max" : { 
"username" : "user122468", 


age" : 68 




















比 ， 对 了 
































如 果 




















: {"age" 
例子 中 我 们 可 
字段 的 范围 可 


以 














14.3.2” 拆 分 块 


mongos 会 记录 在 每 个 块 中 插入 了 多 少数 据 ， 
就 会 检查 是 否 需 要 对 块 进 行 


1, 


个 给 定 的 用 户 名 (或 者 是 用 

















年 龄 ) ， mongos 可 轻易 找到 
只 给 定年 龄 ，mongos 就 
几乎 所 有 ) 块 。 如 果 希 望 基 
到 正确 的 块 上 ， 则 需 使 用 

"userna 
出 一 个 结 
能 会 出 现在 多 个 块 中 。 




















得 























i 必须 查看 所 有 
于 age 的 查询 
“相反 ”的 片 


me" 
ve: EF 

































































， 如 图 14-1 和 


Z] 














-n mongos% 
元 信息 。 块 拆 分 
rig EAT BH AS 5) 
建新 的 块 文档 ， 




















Jo 


只 需 








14-2 所 示 。 如 
ti 会 在 配置 服务 器 
改变 块 的 元 数据 即 可 ， 


果 块 确实 





所 对 应 的 文档 。 但 


上 更 新 这 个 甘 





(或 者 


能 够 被 


: 1}。 从 这 个 





























进 








值 ) 。 


踪 器 ， 同 时 为 新 




















的 块 


行 拆 分 时 ， 
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新 的 追踪 器 。 


忆 置 服务 器 会 创 
同时 修改 昌 的 块 范围 〈 即 max 
拆 分 完成 后 ，mongos 会 重 置 对 原始 块 的 
创建 


追 





op pg mongos 


拆 分 
HEA 





图 14-1 收 到 客户 端 发 起 的 写 请 求 时 ，mongos 
Se hor BE AER BP E 





mongos 
拆 分 请 求 


拆 分 
HER 























图 14-2 WRIA BI TORAS, mongos 就 会 
向 分 片 发 起 一 个 针对 该 拆 分 点 的 拆 分 请 求 


mongos 问 分 片 询问 某 块 是 否 需 被 拆 分 时 ， 分 片 会 
对 块 大 小 进行 粗略 的 计算 。 如 果 发 现 块 正在 不 断 
变 大 ， 它 就 会 计算 出 合适 的 拆 分 点 ， 然 后 将 这 些 
信息 发 送 给 mongos， 如 图 14-3 所 示 。 

















mongos 


分 一 上 | 





图 14-3 ”分 片 计算 块 的 拆 分 点 ， 并 将 这 些 信息 
发 回 mongos 


分 片 有 时 可 能 会 找 不 到 任何 可 用 的 拆 分 点 pal 
此 块 较 大 ) ， “By MEO. 具有 相 
同 片 键 的 文档 \ 须 保存 在 相同 的 块 中 ， 因 此 块 只 

能 在 片 键 的 值 发 生变 化 的 点 对 块 进行 拆 分 。 例 
如 ， 如 果 片 键 的 值 等 于 age 的 值 ， 则 下 列 块 可 在 

































































片 键 发 生变 化 的 点 被 拆 分 : 

{"age" : 13, "username" : "ian"} 
{"age" : 13, "username" : "randolph"} 
a // 拆 分 点 


{"age" : 14, "username" : "randolph"} 











































































































































































































{ "age 14, "username" "eric"} 

{"age 14, "username" "hari"} 

{"age 14, "username" "mathias"} 
ere a // 拆 分 点 

{"age 15, "Username" "greg"} 

{"age 15, "Username" "andrew"} 
mongos 无 需 在 每 个 可 用 的 拆 分 点 对 块 进行 拆 分 ， 
但 拆 分 时 只 能 从 这 些 拆 分 点 中 选择 一 个 。 

例如 ， 如 果 块 包含 下 列 文档 ， 则 此 块 不 可 拆 分 ， 
除非 应 用 开始 插入 不 同 片 键 的 文档 : 

{"age" : 12, "username" "kevin"} 
{"age" : 12, "username" "spencer" } 
{"age" : 12, "username" "alberto"} 
{"age" : 12, "username" "tad"} 

忆 此 ， 拥 有 不 同 的 片 键 值 是 非常 重要 的 。 其 他 重 
要 属性 会 在 下 一 章 讲 到 。 

如 果 在 mongos 试 图 进行 拆 分 时 有 一 个 配置 服务 器 
挂 了 ， 那 么 mongos 就 无 法 更 新 元 数据 ， 如 图 14-4 
所 示 。 在 进行 拆 分 时 ， 所 有 配置 服务 器 都 必须 可 
j 且 可 达 。mongos 如 果 不 断 接收 到 块 的 写 请 求 ， 

分 与 拆 分 失败 的 循环 中 。 只 要 配 






































则 会 处 于 尝试 拆 














服务 器 不 可 用 了 











拆 分 ， 拆 分 














就 无 法 进行 ， 





imongos 不 断 发 起 的 拆 分 请 求 就 会 拖 慢 mongos 和 当 
前 分 片 ( 每 次 收 到 的 写 请 求 都 会 重复 图 14-1 到 图 
14-4 演 示 的 过 程 ) 。 这 种 mongos 不 断 重 复发 起 拆 
分 请 求 却 无 法 进行 拆 分 的 过 程 叫做 拆 分 风暴 

Csplit storm) 。 防 止 拆 分 风暴 的 唯一 方法 是 尽 可 

能 保证 配置 服务 器 的 可 用 和 健康 。 也 可 重启 

mongos， 重 置 写 入 计数 器 ， 这 样 它 就 不 再 处 于 拆 
TREA So 



































mongos 


拆 分 
RHES 





图 14-4 ”mongos 选 择 一 个 拆 分 点 ， 然 后 试图 将 
这 些 信息 通知 给 配置 服务 器 ， 但 是 配置 服务 器 
不 可 达 。 因 此 ， 它 仍 位 于 这 个 块 的 拆 分 闪 值 

点 。 随 后 的 任何 写 请 求 都 会 重复 上 面 的 过 程 
















































































男 一 个 问题 是 ，mongos 可 能 不 会 意识 到 它 需 要 拆 


分 一 个 较 大 的 块 。 并 没有 一 个 全 局 的 计数 器 用 于 














追踪 每 个 块 到 底 有 多 大 。 每 个 mongos 只 是 计算 其 
收 到 的 写 请 求 是 否 达 到 了 特定 的 阔 值 点 (如 图 14- 
5 所 示 )〉 。 也 就 是 说 ， 如 果 mongos 进 程 频繁 地 上 

线 和 宕 机 ， 那 么 mongos 在 再 次 宕 机 之 前 可 能 永远 
FEW AE WIA BIRT BUEN SR, AER 
会 变 得 越 来 越 大 ， 如 图 14-6 所 示 。 





























图 14-5” 随 着 mongos 进 程 不 断 执行 写 请 求 ， 它 





们 的 计数 器 也 会 不 断 增 长 ， 直 至 拆 分 阀 值 点 
























































图 14-6 人 T 它们 的 计 
数 器 可 能 永远 也 不 会 到 达 闵 值 点 ， 因 此 块 的 增 
长 不 存在 最 大 值 


防止 这 种 情况 发 生 的 第 一 种 方式 是 减少 mongos 进 
程 的 波动 。 尽 可 能 保证 mongos 进 程 可 用 ， 而 不 是 
在 需要 的 时 候 将 其 开启 ， 不 需要 的 时 候 又 将 其 关 


















































掉 。 然 而 ， 实 际 部 署 中 可 能 会 发 现 ， 维 持 不 需要 
的 mongos 持 续 运 行 开 销 过 大 。 这 时 可 选用 另 一 种 

方式 : 使 块 的 大 小 比 实际 预期 稍 小 些 ， 这 样 就 更 
容易 达到 拆 分 阔 值 点 。 


可 在 启动 mongos 时 指定 --nosplit 选 项 ， 从 而 关 
闭 块 的 拆 分 。 


14.4 均衡 器 


均衡 器 (balancer) 负责 数据 的 迁移 。 它 会 周期 
性 地 检查 分 片 间 是 否 存在 不 均衡 ， o 则 
会 开始 块 的 迁移 。 虽 然 均衡 器 通常 被 看 作 是 单一 
实体 ， 但 每 个 mongos 有 时 也 会 扮演 均衡 器 的 角 
色 。 

















































































































每 隔 几 秒 钟 ，mongos 就 会 尝试 变 身 为 均衡 器 。 如 
果 没 有 其 他 可 用 的 均衡 器 ，mongos 就 会 对 整个 集 
群 加 锁 ， 以 防止 配置 服务 器 对 集群 进行 修改 ， 然 
后 做 一 次 均衡 。 均 衡 并 不 会 影响 mongos 的 正常 路 
所 以 使 用 mongos 的 客户 端 不 会 受到 影 
吧 。 


查看 config.locks 集 合 ， 可 得 知 哪 一 个 mongos 是 均 
衡器 : 







































































> db.locks 


{ 
" id" 


"ts" 
"when" 
"who" 
"why" 

} 





.findOne({"_id 


"process" 
"state" 
: ObjectId("50cf939c051fcdb8139fc 


"balancer"}) 


"balancer", 
"router-23:27017:135576335 
: @, 


: ISODate("2012-12-17T21:50: 20. 
"router-23:27017:1355763351:18 
"doing balance round" 








config.locks 
为 balancer 
段 可 得 知 当 








合 会 追踪 所 有 集群 范围 的 锁 。_id 
的 文档 就 是 均衡 器 。 从 其 中 的 who 字 

















前 或 曾经 作为 均衡 器 的 mongos 是 哪 一 


个 : 在 本 例 中 是 router-23:27017。 





state 字 段 表明 





均衡 器 是 是 否 正 














0 表示 处 于 非 活动 状态 ，2 


上 在 运行 : 








ART IE 


在 进行 均衡 (1 表示 mongos 正 在 








尝试 得 到 

















锁 ， 但 


mongos 成 为 








还 没有 得 到 ， 





通常 不 会 看 到 状态 1) . 

















匀 衡 器 后 ， 就 会 检查 每 个 集合 











AS 








(balancing threshold) 。 


， 从 而 查看 是 否 有 分 片 达 至 


的 分 块 
I 了 均衡 阀 值 
不 均衡 的 表现 指 ， 一 个 























分 片 明显 比 ] 





有 多 种 不 同人 











AES AE. ER BOA 
大 越 能 承受 不 均衡 状 


Ahab H 


青 况 : 集合 














仿 ) o 如 果 
进行 再 分 布 ， 











检测 到 不 均衡 





均衡 器 就 会 开始 对 块 
有 数量 相当 的 块 。 
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DME REN a H 
































Sy 




















如 果 没 有 集 
均衡 器 的 角 1 


假如 有 一 些 
块 迁移 。 它 会 
块 ， 并 询问 该 分 片 是 否 
拆 分 。 完 成 必要 的 拆 分 后 ， 
量 较 少 的 机 器 上 




















合 达 到 均衡 闷 值 ，mongos 就 不 再 充当 
色 了 。 




















合 到 达 了 闵 值 ， 均 衡器 则 会 开始 做 








从 负载 比较 大 的 分 片 中 选择 一 个 























使 用 集群 的 应 


























迁移 完成 之 前 
的 块 上 。 如 果 
问 旧 位 置 数 


， 所 有 的 读 写 请 求 者 












































TK Es 





误 应 该 














程序 无 需 知道 数据 迁移 ， 在 数据 





需要 在 迁移 之 前 对 块 进行 
就 会 将 块 迁移 至 块 数 








会 被 路 由 到 旧 





元 数据 更 新 完成 ， 那 么 所 有 试图 访 














中 的 mongos 进 程 都 会 得 到 一 个 错误 。 





对 客户 端 不 可 见 ， mongos 会 对 这 些 


















































错误 做 静默 处 理 ， 然 后 在 新 的 分 片上 重新 执行 之 
前 的 操作 。 


有 时 会 在 mongos 的 日 志 中 看 到 “una 








ble to 





setShardVersion” 的 信息 ， 这 是 一 种 很 常见 的 





务 器 数据 的 新 
执行 之 前 的 请 求 。 
据 ， 则 会 将 数据 返回 给 客户 端 。 除 了 日 志 


录 一 条 错误 日 志 外 ， 整 个 过 程 好 像 什 么 错误 都 没 





错误 。mongos 在 收 到 这 种 错误 时 ， 


会 查看 配置 服 











位 置 ， 并 更 新 块 分 布 表 ， 然 后 重新 
如 果 成 功 从 新 的 位 置 得 到 了 数 

















有 发 





E 过 一 样 。 
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会 记 





























于 配置 服务 器 不 可 | 














导致 mongos 无 法 获取 






























































9 新 位 置 ， 则 会 向 客户 端 返 回 错误 。 所 以 ， 应 
J 能 保证 配置 服务 器 处 于 可 用 状态 。 














第 15S 章 ”选择 片 键 


使 用 分 片 时 ， 最 重要 也 是 最 困难 的 任务 就 是 选择 
数据 的 分 发 方式 。 需 要 理解 MongoDB 的 数据 分 发 
机 制 才能 够 做 出 明智 的 选择 。 本 章 则 在 帮助 大 家 
更 好 地 选择 片 键 ， 内 容 包 括 : 


。 如 何在 多 个 可 用 的 片 键 中 做 出 选择 ; 
。 不同 使 用 场景 中 的 片 键 选择 ; 
。 哪些 键 不 能 作为 片 键 ; 




























































































自 定义 数据 分 发 方式 的 可 选 策略 ; 
如 何 手动 对 数据 分 片 。 


由 于 前 几 章 已 经 讲述 了 分 片 的 基本 知识 ， 所 以 本 
章 假设 大 家 对 分 片 已 有 基本 的 了 解 。 


15.1 检查 使 用 情况 


对 集合 进行 分 片 时 ， 要 选择 一 或 两 个 字段 用 于 拆 
分 数据 。 这 个 键 〈 或 这 些 键 ) 就 叫做 片 键 。 一 旦 
拥有 多 个 分 片 ， 再 修改 片 键 几乎 是 不 可 能 的 屋 
情 ， 因 此 选择 合适 的 片 键 (或 者 至 少 快速 注意 到 
可 能 存在 的 问题 ) 是 非常 重要 的 。 


为 了 选择 合适 的 片 键 ， 需 了 解 自己 的 a 
片 键 是 如 何 对 应 用 程序 的 请 求 进行 分 发 的 。 
















































































































































































问题 不 太 好 描述 ， 可 以 尝试 一 些小 例子 ， 或 者 是 


在 


和 解释 说 明 ， 
上 试 一 试 。 


集合 进行 分 片 前 ， 先 回答 以 下 问题 。 



































备用 数据 集 上 做 一 些 实验 。 本 节 含有 大 量 图 
但 最 好 的 方式 还 是 在 自己 的 数据 
































oe 
































。 计划 做 多 少 个 分 片 ? 拥有 3 个 分 乒 的 集群 比 
























































拥有 1000 个 分 片 的 集群 更 具有 灵活 性 。 随 着 
集群 变 得 越 来 越 大 ， 不 应 做 那些 需要 查询 所 

















有 分 片 的 查询 ， 因 此 几乎 所 有 查询 都 须 包 含 





片 键 。 











。 分 上 请 是 为 了 减少 读 写 延迟 吗 ? GERRA 
操作 花费 的 时 间 ， 如 写 操作 花费 20 毫 秒 ， 但 
我 们 需要 将 其 缩减 至 10 毫 秒 ) 。 降 低 写 延迟 


"分 片 是 

















确保 请 


分 片 是 






































为 了 


能 够 


求 被 ] 
为 了 

















A 
9 HJ 


























的 方式 通常 是 将 请 求 发 送 到 地 理 位 置 更 近 的 


服务 器 或 者 是 更 强大 的 机 器 上 。 
4 



































ase hee? (吞吐 量 指 





























在 同一 时 间 能 够 处 理 的 请 求 数 量 : 集群 
20 上 毫秒 内 处 理 1000 次 写 请 求 ， 但 我 们 
在 20 毫 秒 内 处 理 5000 次 写 请 

。 增 加 吞吐 量 通 常 需要 提高 并 行 性 ， 并 





























均衡 地 分 发 到 各 集群 成 员 上 。 
增加 系统 资源 吗 ? Ci, EGB 














提供 MongoDB 更 多 的 可 用 RAM) 。 如 果 











能 会 希望 尽量 保持 工作 集 较 小 。 








根据 这 些 问 题 来 对 不 同 片 键 进行 评估 ， 并 判断 所 








选 片 键 是 否 适用 














所 需 的 目标 查 


吐 量 或 者 减少 读 








巧 ， 这 样 做 可 
15.2 ”数据 分 

















以 达到 要 求 吗 ? 
} 发 





自己 的 情况 。 这 样 做 能 够 提供 
询 吗 ?能 够 按 所 需 方式 提高 系统 知 
写 延 迟 吗 ? 如 需 保 持 了 

















工作 集 的 小 











拆 分 数据 最 常 
键 ees 
置 (location- 























based) 的 片 键 。 














key) 





的 数据 分 发 方式 有 三 种 ， 升序 片 
、 随 机 分 发 的 片 键 和 基于 位 
也 有 一 些 其 








他 类 类 型 














的 键 可 供 使 用 








， 但 大 部 分 都 属 了 











下 几 节 会 分 别 4 


15.2.1 FHF H gÈ 





升序 片 键 通常 有 点 类 似 于 "date" 


是 ObjectId， 


介绍 这 三 种 方式 。 











于 这 三 种 类 别 。 


以 


字段 或 者 





bh AS By 











是 一 种 会 














段 。 
很 少 出 
导入 数据 。 














假设 我 
的 集合 中 的 " 
么 集合 





就 会 依据 不 同 的 "_ 





增长 的 主键 是 升序 键 的 另 一 个 例子 ， 
现在 MongoDB 中 ， 除 非 要 从 j 





门 依据 升序 键 做 分 片 ， 如 
_id" 键 。 如 果 基 于 " 





随 着 时 间 稳 定 增 长 
































其 他 数 























区 用 ObjectId 
_id" 分 片 ， 那 


























id" yè Hl 





被 拆 分 为 多 个 











块 ， 如 图 15-1 所 示 。 这 些 块 会 分 发 在 我 们 这 个 于 

















有 分 片 的 集群 中 《比如 说 3 个 分 片 )， 如 图 15-2 


ZN o 








所 


$minKey -> Objectld(''5112fa61b4a4b396ff960262") 


Objectld("5112fa61b4a4b396ff960262") -> 
Objectld("5112fa9bb4a4b396ff96671b") 


Objectld("5112fa9bb4a4b396ff9667 1b") -> 
Objectid("5112faa0b4a4b396ff9732db") 


Objectld("5112faa0b4a4b396ff9732db") -> 
Objectld("5112fabbb4a4b396197b40") 


Objectld("5112fabbb4a4b396ff97fb40") -> 
Objectld("5112fac0b4a4b396ff98c6f8") 


Objectld("5112fac0b4a4b396ff98c6f8") -> 
Objectld("5112fac5b4a4b396ff998b59") 


Objectid("5112fac5b4a4b396ff998b59") -> 
Objectld("5112facab4a4b396ff9a56c5") 


Objectld("5112facab4a4b396ff9a56c5") -> 
Objectld("5112facfb4a4b396ff9b1b55") 


Objectld("5112facth4a4b396ff9b1b55") -> 
Objectld("5112fad4b4a4b396ff9bd69b") 


Objectld("5112fad4b4a4b396ff9bd69b") -> 
Objectld("5112fae0b4a4b396ff9d0ee5") 


Objectld("5112fae0b4a4b396ff9d0ee5") -> SmaxKey 











图 15-1 集合 依据 不 同 的 0bjectId 范 围 被 拆 


分 ， 每 个 范围 都 是 一 个 块 


假设 要 创建 一 个 新 文档 ， 它 会 位 于 哪个 块 呢 ? 











J 


























为 ObjectId("5112fae8@b4a4b396ff9deee5") 
到 $maxKey 的 块 。 这 个 块 叫做 最 大 块 Cmax 
chunk) ， 因 为 该 块 包含 有 $maxKey。 


如 果 再 插入 一 个 文档 ， 它 也 会 出 现在 最 大 块 中 。 
事实 上 ， 接 下 来 的 每 个 新 文档 都 会 被 插入 到 最 大 
块 中 ! 每 一 个 插入 文档 的 "_id" 字 段 值 都 会 比 之 
前 文档 的 "id" 字 段 值 更 接近 正 无 穷 〈 因 

为 0bjectId 一 直 在 增长 ) ， 所 以 这 些 文档 都 会 
插入 到 最 大 块 中 。 




































































分 片 0000 


Objectid("5112fa9bb4a4b396ff9667 1b") -> 
Objectid("5112faa0b4a4b396ff9732db") 


Objectid("5112faa0b4a4b396ff9732db") -> 


Objectid("5112fabbb4a4b396ff97 fb40") 


Objectid("5112fabbb4a4b396ff97fb40") -> 
Objectld("'5112fac0b4a4b3 96ff98c6f8") 





43 Fr OOO1 
$minkey -> Objectld("5112fa61b4a4b3 96ff960262") 


Objectid("5112fa61b4a4b396ff960262") -> 
Objectid("5112fa9bb4a4b396ff9667 1b") 


Objectid("5112facOb4a4b396ff98c6f8") -> 
Objectid("5112fac5b4a4b396ff998b59") 


Objectid("5112fac5b4a4b396ff998b59") -> 
Objectid("5112facab4a4b396ff9a56c5") 





43 Fr 0002 


Objectld("5112facab4a4b396ff9a56c5") -> 
Objectld("5112facfb4a4b396ff9b1b55") 


Objectld("51 12facfb4a4b396ff9b1b55") -> 
Objectid("5112fad4b4a4b396ff9bd69b") 


Objectld("5112fad4b4a4b396ff9bd69b") -> 
Objectid("5112fae0b4a4b396ff9d0eeS") 


Objectid("5112faeOb4a4b396ff9d0ee5") -> SmaxKey 





图 1$-2” 块 在 分 片 中 是 以 随机 顺序 分 发 的 


这 样 会 带 来 一 些 有 趣 的 属性 ， 通 常 都 是 些 不 良 属 
性 。 首 先 ， 所 有 的 写 请 求 都 会 被 路 由 到 一 个 分 片 
(本 例 中 是 shard0002) 中 。 该 块 是 唯一 一 个 不 断 
增长 和 拆 分 的 块 ， 因 为 它 是 唯一 一 个 能 够 接收 到 
插入 请 求 的 块 。 随 着 新 数据 的 不 断 插 入 ， 该 最 大 
块 会 不 断 拆 分 出 新 的 小 块 ， 如 图 15-3 所 示 。 



























































Objectld("5112fad4b4a4b396ff9bd69b") -> 
Objectld("5112fae0b4a4h396ff9d0ee5") 


Objectld("5112fad4b4a4b396ff9bd69b") -> 
Objectld("5112faeOb4a4b396ffodOees") 
Objectid("5112fae0b4a4b396ff9d0ees") -> 
Objectld("5112ff8fb4a4b396ff9dc1c4") 
Objectld("5112ff8fb4a4b396ff9dc1c4") -> 
Objectld("51 12f796b4a4b396ff9ec66c") 
Objectld('5112ff96b4a4b396ffgec66c") -> SmaxKey 


图 15-3 ”最 大 块 不 断 增长 ， 不 断 被 拆 分 为 多 个 
块 


Objectld("5112faeOb4a4b396ff9d0ee5") -> SmaxKey 




















这 种 模式 经 常会 导致 MongoDB 的 数据 均衡 处 理 变 
得 更 为 困难 ， 因 为 所 有 的 新 块 都 是 由 同一 分 片 创 
建 的 。 因 此 ，MongoDB 必 须 不 断 将 一 些 块 移 至 其 
他 分 片 ， 而 不 能 像 在 一 个 比较 均衡 分 发 的 系统 中 
那样 ， 只 需 纠 正 那些 比较 小 的 不 均衡 就 好 了 。 

































































15.2.2 ”随机 分 发 的 片 键 


另 一 种 方式 是 随机 分 发 的 片 键 。 随 机 分 发 的 键 可 
以 是 用 户 名 、 邮 件 地 址 、UDID (Unique Device 
IDentifier， 唯 一 设备 标识 符 ) 、MD5 散 列 值 ， 或 
者 是 数据 集中 其 他 一 些 没 有 规律 的 健 。 


假如 片 键 是 0 和 1 之 间 的 随机 数 ， 各 分 片上 随机 分 
发 的 块 如 图 15-4 所 示 。 
























































43 Fr 0000 


sminKey -> 
0.07152752857759748 
0.5050852404345105 -> 0.5909494812833331 





0.59094948 12833331 -> 0.6969766499990353 


43 0001 


0.6969766499990353 -> 0.8400606470845913 
0.8400606470845913 -> 0.9190519609736775 
0.9190519609736775 -> 0.9999498302686232 
0.9999498302686232 -> 
$maxKey 
47 Fr 0002 
0.07152752857759748 -> 0.15425320872988635 
0.15425320872988635 -> 0.25743183243034107 





0.25743183243034107 -> 0.3640577812240344 
0.3640577812240344 -> 0.5050852404345105 





图 15-4 ”如 前 一 节 所 述 ， 块 随机 地 分 发 在 引 


Ho 





群 


Y 











随 着 更 多 的 数据 被 插入 ， 数 据 的 随机 性 意味 着 
新 插入 的 数据 会 比较 均衡 地 分 发 在 不 同 的 块 中 。 
可 以 试 着 插入 10000 个 文档 ， 来 验证 一 下 会 发 4 
TA: 
































mT 








> var servers = {} 
> var findShard = function (id) { 
; var explain = db.random.find({_id: 
for (var i in explain.shards) { 
var server = explain.shards[i 
if (server.n == 1) { 
if (server.server in serv 
servers[server.server 
} else { 
servers[server.server 

} 


} 
} 


> for (var i = ð; i < 10000; i++) { 

# var id = ObjectId(); 
db.random.insert({"_id" : id, "x" 
findShard(id); 








> servers 


{ 
"spock: 30001" : 2942, 
"spock: 30002" : 4332, 
"spock: 30000" : 2726 
} 








由 于 写 入 数据 是 随机 分 发 的 ， 各 分 片 增长 的 速度 
应 大 致 相同 ， 这 就 减少 了 需要 进行 迁移 的 次 数 。 


使 用 随机 分 发 片 键 的 唯一 次 端 在 于 ，MongoDB 在 
随机 访问 超出 RAM 大 小 的 数据 时 效率 不 高 。 然 
而 ， 如 果 拥有 足够 多 的 RAM 或 者 是 并 不 介意 系统 
性 能 的 话 ， 使 用 随机 片 键 在 集群 上 分 配 负 载 是 非 
常 好 的 。 





















































15.2.3 ”基于 位 置 的 片 键 






































基于 位 置 的 片 键 可 以 是 用 户 的 卫 、 经 纬度 ， 或 者 
是 地 址 。 位 置 片 键 不 必 与 实际 的 物理 位 置 字段 相 
K: 这 里 的 “位 置 比 较 抽 象 ， 数 据 会 依据 这 个 “位 
置 ” 进 行 分 组 。 无 论 如 何 ， 所 有 与 该 键 值 比较 接 
近 的 文档 都 会 被 保存 在 同一 范围 的 块 中 。 这 样 可 
以 比较 方便 地 将 数据 与 相应 的 用 户 ， 以 及 相关 联 
的 数据 保存 在 一 起 。 













































































































































































例如 ， 假 设 我 们 有 一 个 集合 的 文档 是 按照 他 地 址 
进行 分 片 的 。 文 档 会 依据 TT 地 址 被 分 成 不 同 的 
块 ， 并 随机 分 布 在 集群 中 ， 如 图 15-5 所 示 。 





























分 片 0000 分 片 0001 分 片 0002 


$minKey -> "072.034.009.012" -> "002.075.101.096" -> 
"002.075.101.096" "090.118.120.031" "022.089.076.022" 


"055.081.104.118" -> "090.118.120.031" -> "022.089.076.022" -> 


"072.034.009.012" "127.126.116.125" "038.041.058.074" 
"127.126.116.125" -> "038.041.058.074" -> 
Smaxkey "055.081.104.118" 
15-5 ”下 地 址 集合 中 的 块 分 发 情况 


如 果 和 希望 特定 范围 的 块 出 现在 特定 的 分 片 中 ， 互 
以 为 分 片 添加 tag， 然 后 为 块 指定 相应 的 tag 。 在 
本 例 中 ， 假 如 我 们 希望 特定 范围 的 下段 出 现在 特 
定 的 分 片 中 ， 比 如 让 “56.*.*.*” 〈 美 国 邮 政 署 的 卫 
段 〉 出 现在 shard0000， 让 “17.*.*.*” (苹果 公司 的 
卫 段 ) 出 现在 shard0000 或 shard0002 上 。 我 们 并 不 
关心 其 他 的 下 出 现在 什么 位 置 we 过 为 分 片 指 
定 tag， 请 求 均衡 器 实现 该 指令 













































































> sh.addShardTag("shard@ee@e", "USPS") 
> sh.addShardTag("shard@eee", "Apple") 
> sh.addShardTag("shard@ee@2", "Apple") 




















然后 ， 创 建 下 列 规则 ; 


> sh.addTagRange("test.ips", {"ip" : "956. 
... {"ip" : "057.000.000.000" }, "USPS") 




















这 样 就 会 将 所 有 耳 地 址 大 于 等 于 $6.0.0.0 和 小 于 
57.0.0.0 的 文档 分 发 到 标签 为 “USPS” 的 分 片上 。 
接 下 来 ， 再 为 苹果 公司 的 卫 段 添加 一 条 规则 ; 


> sh.addTagRange("test.ips", {"ip" : "617. 
... {"ip" : "@18.000.000.000"}, "Apple") 
























































均衡 器 在 移动 块 时 ， 会 试图 将 这 些 范围 的 块 移动 
到 这 些 分 片上 。 注 意 ， 该 过 程 不 会 立即 生效 。 没 
有 被 打 过 标签 的 块 仍 会 正常 移动 。 均 衡器 会 继续 
尝试 将 块 均衡 地 分 发 在 不 同 的 分 片上 。 


15.3 “ 片 键 策 略 


本 节 我 们 将 学 习 针对 不 同类 型 
键 选 项 。 
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15.3.1 AUF Ar 




















如 果 追 求 的 是 数据 加 载 速度 的 极致 ， 那 么 散 列 片 
键 (Hashed Shard Key) 是 最 佳 选 择 。 散 列 片 键 可 
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其 他 任何 键 随机 分 发 ， 





查询 中 使 用 升序 键 ， 但 同 


发 的 话 ， 散 列 片 键 








大 











时 又 希望 写 入 数据 随机 
会 是 个 





此 ， 如 果 打 算 在 大 量 
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非常 好 的 选 





























端 是 无 法 使 用 散 
。 如 无 需 做 范围 














[GT 

















建 一 个 散 列 片 键 ， 














列 片 键 做 指定 
查询 ， 那 么 散 列 片 键 训 


f 先 要 创建 散 列 索引 ， 


标的 范围 
EAE 
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> db.users.ensureIndex({"username" 


: "hash 

























































































然后 对 集合 分 片 : 

> sh.shardCollection("app.users", {"userna 
{ "collectionsharded" : "app.users", "ok" 
如 果 在 一 个 不 存在 的 集合 上 创建 散 列 片 
键 ，shardCollection 的 行为 会 比较 有 趣 : 它 假 
设 我 们 希望 对 数据 块 进行 均衡 分 发 ， 所 以 会 立即 
创建 一 些 空 的 块 ， 并 将 这 些 块 分 发 在 集群 中 。 例 
如 ， 在 创建 散 列 片 键 之 前 ， 集 合 如 下 : 

> sh.status() 

--- Sharding Status --- 

sharding version: { "_id" : 1, "version" 


shards: 


{ ”id”: "shard6668"， "host" 

{ ”id”: "shardeeei", "host" 

{ "id" : "shardeee2", "host" 
databases: 

{ "id" : "admin", "partitione 

{ "id" : "test", "partitioned 




















shardCollection 命 令 返回 后 ， 每 个 分 片上 立即 
出 现 了 两 个 块 ， 并 均衡 地 分 发 在 整个 集群 中 : 






































> sh.status() 
--- Sharding Status --- 
sharding version: { "_id" : 1, "version" 
shards: 
{ "id" : "shardeeee", "host" : "1 
{ "id" : "shardeeei", "host" : "1 
{ "id" : "shardeee2", "host" : "1 
databases: 
{ "id" : "admin", "partitioned" 
{ "id" : "test", "partitioned" 
test. foo 
shard key: { "username" D 
chunks: 
shard6666 2 
shard6661 2 
shard6662 2 
{ "username" : { "$MinKey" 
-->> { "username" : Num 
on : shardeeee { "t" 








"username" : NumberLong(" 


"username" : NumberLong(" 


"username" : NumberLong(@ 


"username" : NumberLong(" 


"username" : NumberLong(" 


-->> { "username" : Num 
on : shardeeee { "t" : 


-->> { "username" : Num 
on : shardeee1 { "t" : 


-->> { "username" : Num 
on : shardeee1 { "t" : 


-->> { "username" : Num 
on : shardeee2 { "t" : 


-->> { "username" : { " 
on : shardeee2 { "t" : 














dn 
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k 出 


在 集合 中 还 没有 文档 ， 但 当 插 入 新 文档 
求 一 开始 就 会 


na Aye ft. 





























被 均衡 地 分 发 到 不 同 的 分 
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动 时 再 将 写 请 




















分 片上 。 


使 月 
使 月 














日 散 列 片 键 存在 
月 unique 选 项 。 





使 月 


。 通 常 需要 等 待 
青 求 分 发 到 其 他 分 片上 。 使 用 这 种 自 
力 机 制 ， 数 据 块 从 一 开始 就 会 均衡 地 分 发 在 所 有 


“A 


块 的 增长 与 拆 分 ， 直 到 块 移 









































的 局 限 性 。 首 先 ， 不 能 
次 ， 与 其 他 片 键 一 样 ， 不 能 

















其 











有 数组 字段 。 最 后 注意 ， 浮 点 型 的 值 会 先 被 取 











整 ， 然 后 才 会 进行 散 列 ， 所 以 1 和 1.999999 会 得 到 


相同 的 散 列 值 。 


15.3.2 ”GridFS 的 散 列 片 键 











在 对 GridFS 集 合 做 分 片 之 前 ， 确 保 已 理解 了 
GridFS 的 数据 存储 机 制 〈 第 6 章 有 详细 介绍 ) 。 


在 接 下 来 的 介绍 中 ， 
存在 多 重 含义 ， 因为 GridFS 会 将 文件 拆 分 为 块 ， 

而 分 片 也 会 将 集合 拆 分 为 块 。 因 此 ， 在 本 章 后 续 
内 容 中 ， 分 别 以 “GridFS 块 ?和 “分 片 块 ?表示 这 两 











种 块 。 





























“H? (chunks) 这 一 术语 会 


























GridFS 集 合 通常 来 说 非常 适合 做 分 片 ， 因 为 它们 

















键 : {"_id" 

















居 。 但 是 ， 在 fs.chunks 上 自 








动 创建 的 索引 并 不 是 特别 适合 作为 分 片 
: 1} 是 一 个 升序 键 ，{"files_id" 


: 1, "n" : 1} 使 用 了 fs.files 的 _ id 字段 ， 


此 它 也 是 一 个 升序 键 。 

















但 是 ， 如 果 在 "files_ id' 字段 上 创建 散 列 索 





引 ， 则 每 个 文件 





都 会 


一 个 文件 只 能 被 包含 


常 好 的 ， 因 为 ， 


By 





上 ， 而 读 取 文 件 
BU Ay. 





By 














e 但 是 
在 一 个 单一 的 块 中 。 es 
二 震 求 被 均衡 地 分 发 到 所 有 分 片 
居 时 只 需 查 询 一 个 单一 的 分 片 












































为 实现 这 种 策略 ， 


"has 





键 ) 。 


必须 在 {"files id" 














hed"} 上 创建 























新 的 索引 【在 本 书 编写 之 
时 ， mones eee 复合 索引 的 子 集 作为 片 
然后 依据 这 个 字段 对 集合 分 片 : 





























> db.fs.chunks.ensureIndex({"files_id" 
> sh.shardCollection("test.fs.chunks", {"f 
{ "collectionsharded" : "test.fs.chunks", 





另外 提醒 一 下 ， 


























| 于 人 .files 集 合 比 氏 .chunks 集 合 小 


得 多 ，fs.files 集 合 可 能 需要 做 分 片 ， 也 可 能 不 需 





15.3.3 ”流水 策略 














如 果 
能 会 





要 。 可 以 对 该 集合 做 分 片 ， 但 通常 没什么 必要 








有 一 些 服务 器 比 其 他 服务 器 更 强大 ， 我 们 可 


希望 让 这 些 强 大 的 服务 器 处 理 更 多 的 负载 。 












































比如 说 ， 假 如 有 一 个 使 用 SSD 的 分 片 能 够 处 理 10 





fir eal nA 


分 片上 。 


IKIH 























F 其 他 机 器 《使 用 转 式 磁盘 ) 的 负载 。 幸 运 的 
是 ， 我 们 有 10 个 其 他 分 片 。 可 强制 将 所 有 新 数据 
插入 到 SSD， 然 后 让 均衡 器 将 旧 的 块 移动 到 其 他 
这 样 能 够 提供 比 转 式 磁盘 更 低 的 延迟 。 
























































。 首 先 ， 为 SSD 指 定 











见 这 种 策略 ， 需 将 最 大 范 围 的 块 分 布 在 SSD 




















> sh.addShardTag("shard-name", "ssd") 
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将 升序 键 的 当前 值 一 直到 正 无 穷 范 围 的 块 指定 分 
布 在 SSD 分 片上 ， 以 便 后 续 的 写 入 请 求 均 被 分 发 
到 SSD 分 片上 : 















































> sh.addTagRange("<i>dbName.collName</i>", 
. {"_id" : MaxKey}, "ssd") 

















现在 ， 所 有 的 插入 请 求 均 会 被 路 由 到 这 个 块 上 ， 
这 个 块 始终 位 于 标签 为 ssd 的 分 片上 。 





























但 是 ， 除 非 修改 标签 范围 ， 否 则 从 升序 键 的 当前 
值 一 
片上 。 可 创建 一 个 定时 任务 每 天 更 新 一 次 标签 
围 ， 如 下 : 
























































> Use config 

> var tag = db.tags.findOne({"ns" : "<i>db 
. "max" : {"<i>shardKey</i>" : MaxKey}}) 

> tag.min.<i>shardKey</i> = ObjectId() 

> db.tags.save(tag) 


























这 样 ， 前 一 天 的 块 就 可 以 被 移动 到 其 他 分 片上 
了 。 


策略 的 另 一 浆 端 是 需 做 一 些 修改 才能 进行 扩 


















































展 。 如 果 写 请 求 超出 了 SSD 的 处 理 能 力 ， 想 要 将 
负载 均衡 地 分 布 到 当前 服务 器 和 另 一 台 服 务 器 并 
不 简单 。 


RT ATE EE 服务 器 来 处 理 插 入 流水 ， 或 者 是 
没有 使 用 标签 ， 那 么 不 要 将 升序 键 用 作 片 键 。 否 
则 ， 所 有 写 请 求 都 会 被 路 由 到 同一 分 片上 。 









































































































































15.3.4 多 热点 















































单个 mongod 服 务 器 在 处 理 升 序 写 请 求 时 是 最 有 效 
的 。 这 种 技术 与 分 片 相 ! 突 ， 写 请 求 分 布 在 集群 
中 时 ， 分 片 是 最 高 效 的 。 这 种 技术 会 创建 多 个 热 
点 (最 好 在 每 个 分 片 都 创建 几 个 热点 ) ， 写 请 求 
于 是 会 均衡 地 分 布 在 集群 内 ， 而 在 单个 分 片上 则 
是 以 升序 分 布 的 。 


为 实现 这 种 方式 ， 需 使 用 复合 片 键 (compound 

shard key) 。 复 合 片 键 中 的 第 一 个 值 只 是 比较 粗 
略 的 随机 值 ， 势 也 比较 低 。 可 将 片 键 第 一 部 分 中 
的 每 个 值 想 象 为 一 个 块 ， 如 图 15-6 所 示 。 随 着 插 
入 数据 的 增多 ， 这 种 现象 也 会 随 之 出 现 ， 虽 然 可 
能 不 会 被 分 离 得 这 么 整洁 (注意 图 中 的 $minKey 
行 ) 。 但 是 ， 如 果 插 入 足够 多 的 数据 ， 最 终 会 发 
现 基本 上 每 个 随机 值 都 位 于 一 个 块 中 。 如 果 继 续 





















































































































































插入 数据 ， 最 终 同 一 个 随机 值 则 会 对 应 有 多 个 
块 ， 这 时 候 就 轮 到 片 键 中 的 第 二 部 分 出 马 了 。 











{"state" : "KS", "_id" : SminKey} -> 
{"state" : "KY", "_id" : $minKey} 


{"state" : "KY", "_id" : $minKey} -> 
{"state" : "LA", "_id" : $minKey} 


{"state" : "LA", "_id" : SminKey} -> 
{"state" : "MA", "_id" : $minKey} 


{"state" : "MA", "_id" : SminKey} -> 
{"state" : "MD", "_id" : SminKey} 


{"state" : "MD", "_id" : SminKey} -> 
{"state" : "ME", "_id" : SminKey} 





15-6 ” 块 的 一 个 子 集 。 每 个 块 都 包含 一 个 状 
态 和 一 个 _id 范 围 


片 键 的 第 二 部 分 是 个 升序 键 。 也 就 是 说 ， 在 一 个 
内 ， 值 总 是 增加 的 ， 如 图 15-7 中 的 文档 样 例 所 
妹 此， 如 果 每 个 分 片 拥 有 一 个 块 ， 会 是 非常 
美的 配置 ， 写 请 求 在 每 个 分 片 内 都 是 升序 的 ， 
图 1$-8 所 示 。 当 然 ， 在 多 个 分 片 中 拥有 多 个 
， 每 个 块 拥 有 多 个 热点 ， 这 种 方式 并 不 易于 扩 
添加 一 个 新 的 分 片 不 会 获得 任何 写 请 求 ， 因 
为 这 个 分 片上 没有 热点 块 。 因 此 ， 我 们 会 希望 在 
每 个 分 片上 拥有 几 个 热点 块 〈 以 提供 增长 空 
HD 。 然 后 ， 热 点 块 不 能 过 多 。 少 数 的 热点 块 能 
够 保持 升序 写 请 求 的 效率 。 但 是 ， 在 一 个 分 片上 
拥有 1000 个 “热点 "的话 ， 其 实 写 请 求 就 相当 于 是 
完全 随机 的 了 。 






































































































































































































































{"state" : "MA", ”id" : Objectld("511bfb9e17d55c62b237 1f1d") } 


{"state": "NY", "_id" : Objectld("511bfb9e17d55c62b2371fle") } 


{"state" : "CA", id : Objectld("511bfb9e17d55c62b2371f1f") } 


{"state" : "NY", "_id" : Objectld("511bfb9e17d55c62b2371f20") } 


{"state" : "MA", "_id" :Objectld("511bfb9e17d55c62b2371f21 ) } 


{"state" : "MA", "_id" : Objectld("511bfb9e17d55c62b2371f22") } 


{"state" : "NY", "_id" : Objectld("511bfb9e17d55c62b2371f23") } 


{"state" : "CA", "_id" : Objectld("511bfb9e17d55c62b2371f24") } 


{"state" : "CA", "_id" : Objectld("511bfb9e17d55c62b2371f25") } 





图 15-7: 插入 文档 的 一 个 样 例 。 注 意 ， 所 有 的 
_id 都 是 升序 的 








{"state" : "CA", "_id" : 
{"state": "CO", "_id" : SminKey} 


{ "state" :"CA","_id" : Objectld("'511bfb9e17d55c62b237 1f1f") } 


{ "state" : "CA", "_id" : Objectld("511bfb9e17d55c62b2371f24") } 


{ "state" :"CA","_id" : Objectld("511bfb9e17d55c62b2371f25") } 


{"state" : "MA", "_id" : SminKey} -> 
{"state" : "ME", "_id" : SminKey} 


{ "state" : "MA", "_id" : Objectld("511bfb9e17d55c62b2371f1d") } 


{"state" : "MA', "_id" : Objectid("511bfb9e17d55c62b2371f21") } 


{"state": "MA", "_id" : Objectld("511bfb9e17d55c62b2371f22") } 


{"state" : "NY", "_id" : $minKey} -> 


{'state" : "OH", "_id" : $minKey} 


{"state" : "NY", "_id" : Objectid("511bfb9e17d55c62b2371f1e") } 


{"state" : "NY", "_id" : Objectld("511bfb9e17d55c62b2371f20") } 


{ "state" : "NY", "_id" : Objectld("511bfb9e17d55c62b2371f23") } 





15-8 ”插入 的 文档 被 拆 分 成 了 多 个 块 。 注 
意 ， 在 每 个 块 内 ，_id 都 是 升序 的 


可 将 这 种 配置 想象 成 每 个 块 都 是 一 个 升序 文档 的 
栈 。 每 个 分 片上 拥有 多 个 栈 ， 每 个 栈 都 是 不 断 增 
长 的 ， 直 到 块 被 拆 分 。 一 旦 块 被 拆 分 ， 只 有 一 个 
新 块 会 成 为 热点 块 : ee 
种 “ 死 掉 ”的 状态 ， 且 不 会 再 继续 增长 。 如 果 这 些 
栈 均 衡 地 分 发 在 分 片 中 ， 那么 写 清 求 也 会 被 均衡 
地 分 发 到 不 同 的 分 片上 。 


15.4” 片 键 规则 和 指导 方针 

在 选择 片 键 前 ， 应 注意 一 些 实际 限制 。 
由 于 与 创建 索引 键 的 概念 类 似 ， 因 此 决定 使 用 哪 
ETET A 非常 相 


似 。 事 实 上 ， 我 们 使 用 的 片 键 可 能 常常 就 是 使 用 
最 频繁 的 索引 《或 者 是 索引 的 变种 ) 。 




























































































































































































15.4.1 片 键 限制 





片 键 不 可 以 是 数组 。 在 拥有 数组 值 的 键 上 执 
行 sh.shardCollection()， 则 命令 不 会 生效 。 
向 片 键 插入 数组 值 也 是 不 被 允许 的 。 






















































































































































































































































































文档 一 旦 插入 ， 其 片 键 值 就 无 法 修改 了 。 要 修改 
文档 的 片 键 值 ， 必 须 先 删除 文档 ， 修 改 片 键 的 
值 ， 然 后 重新 搬入。 因此， 应 选择 不 会 被 改变 的 
字段 ， 或 者 是 很 少 发 生 改 变 的 字段 。 

大 多 特殊 类 型 的 索引 都 不 能 被 用 作 片 键 。 特 别 是 
不 能 在 地 理 空 间 索 引 进行 分 片 。 如 前 所 述 ， 使 
散 列 索引 作为 片 键 是 可 以 的 。 

15.4.2 FRA 

不 管 片 键 是 跳跃 增长 还 是 稳定 增长 ， 选 择 一 个 值 
会 发 生变 化 的 键 是 非常 重要 的 。 与 索引 一 样 ， 分 
片 在 势 比较 高 的 字段 上 性 能 更 佳 。 例 

如 ，"logLevel" 键 只 拥 

有 "DEBUG" 、"WARN" 和 "ERROR" 这 几 个 值 。 如 用 
其 作为 片 键 ， 则 MongoDB 最 多 只 能 将 数据 分 为 三 
个 块 《〈 因 为 片 键 只 拥有 三 个 不 同 的 值 ) 。 如 果 键 
拥有 的 值 比较 少 ， 而 且 确 实 希 望 将 这 个 键 用 作 片 
键 ， 则 可 使 用 该 键 与 男 一 个 拥有 多 样 值 的 键 创 建 
一 个 复合 片 键 ， 比 

如 "logLevel" 和 "timestamp"。 注 意 ， 复 合 片 
键 的 势 比 较 高 。 

15.5 ”控制 数据 分 发 





























关内 容 。 








有 时 候 ， 自 动 数 据 分 发 无 法 满足 需求 。 
学 习 过 了 有 关 选 择 片 键 以 及 让 MongoDB 自 动 处 理 
事务 的 内 容 ， 接 下 来 我 们 将 在 本 节 学 习 到 更 多 相 


前 面 已 经 


























随 着 集群 变 得 越 来 越 大 或 者 越 来 越 繁忙 ， 这 些 解 
a ee 有 效 。 但 是 ， 对 于 比 











较 小 的 集群 ， 也 许 我 们 会 
权 。 








望 拥 有 更 多 的 控 各 
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15.5.1 对 多 个 数据 库 和 集合 使 用 一 个 集群 

















MongoDB 将 集合 均衡 地 分 发 到 集群 中 的 分 片上 ， 




































































他 集合 的 数据 有 “价值” 我 们 可 





















































允许 其 他 集合 使 用 它 。 














昂贵 的 服务 器 。 或 者 ， 如 果 
> 们 可 能 只 希望 将 其 用 在 实时 集合 上 












































为 实现 这 种 模式 ， 在 shell 中 运 


行 sh.addSshardTag() 














甫 助 函 数 : 








保存 的 数据 比较 均匀 ， 则 该 方法 非常 有 效 。 

集合 ， 该 集合 的 数据 不 如 
能 不 希望 其 占 
Ma ABADA 








， 而 不 





这 些 情况 下 ， 可 建立 独立 
的 集群 ， 也 可 将 数据 的 保存 位 置 明确 指 





at hh 
定 给 





> sh.addshardTag("shard6666 "， 


"high") 


// shard6661 - no tag 
// shard@@@2 - no tag 


sh.addShardTag("sharde@e@e4", "low") 


> 
> 
> // shard@@e@3 - no tag 
> 
> 


sh.addShardTag("shard@e@e@5", "low") 








然后 可 以 将 不 














同 的 集合 指定 到 不 同 的 分 片 。 例 


























如 ， 对 于 实时 集合 : 
> sh.addTagRange("super.important", {"shardKey" : Mi 
. {"shardKey" : MaxKey}, "high") 
上 面 这 条 命令 的 意思 是 ,，“ 将 该 集合 内 片 键 的 值 

















在 负 无 穷 到 正 








oa > MIME. 保存 到 标签 











为 high 的 分 片上 ”。 也 就 是 说 ， 该 重要 集合 的 所 





有 数据 都 不 
并 不 会 影响 其 
被 均衡 地 分 发 




















会 被 保存 在 其 他 服务 器 上 。 注 意 ， 这 




















他 集合 的 分 发 方式 其 
在 该 分 片 和 其 他 分 片上 。 


y 
È 
> 
> 

















Ht 


同样 地 ， 也 可 
务 器 上 : 


T 























以 将 日 志 集 合 指定 到 比较 便宜 的 服 




















> sh.addTagRange("some.logs", {"shardKey" : MinKey}, 
. {"shardKey" 


: MaxKey}, "low") 














现在 ， 日 志 集 合 
shard0005 上 。 








会 被 均衡 地 分 发 在 shard0004 和 











为 集合 指定 一 个 标签 范围 的 指令 并 不 会 立即 生 
效 。 它 只 是 一 个 对 于 均衡 器 的 指令 ， 运 行 指令 可 
将 集合 移动 到 这 些 目标 分 片上 。 因 此 ， 如 果 整 个 
志 集 合 都 位 于 shard0002 或 者 是 均衡 地 分 发 在 所 
有 分 片上 ， 那 么 需要 消耗 一 定 的 时 间 ， 日 志 集 合 
的 所 有 块 才 会 被 迁移 到 shard0004 和 shard0005 上 。 


再 举 一 个 例子 。 也 许 有 这 样 一 个 集合 ， 我 们 希望 
其 出 现在 除 标签 为 high 的 分 片 以 外 的 任何 分 片 
可 为 所 有 的 非 高 性 能 分 片 添加 一 个 新 的 标 



























































































































































签 ， 创 建 一 个 新 分 组 。 分 片 可 创建 的 标签 多 少 没 
有 限制 : 

> sh.addshardTag("shard6661"， "whatever") 
> sh.addshardTag("shard6662"， "whatever") 
> sh.addshardTag("shard6663"， "whatever") 
> sh.addshardTag("shard6664"， "whatever") 
> sh.addshardTag("shard6665"， "whatever") 














现在 ， 可 指定 该 集合 (名 为 normal.coll) 分 发 
在 这 五 个 分 片上 : 











> sh.addTagRange("normal.coll", {"shardKey" : MinKey 
. {"shardKey" : MaxKey}, "whatever") 














不 能 动态 地 指定 集合 ， 如 “ 当 新 集合 创建 时 ， 将 
其 随机 分 发 到 一 个 分 片上 ”。 但 是 ， 可 使 用 定时 





















































任务 来 做 这 些 事 情 。 
如 

















SE 




















操作 失误 或 是 改变 了 主意 ， 可 使 
J"sh.removeShardTab() "删除 分 片 的 标签 : 











> sh.removeShardTag("shard@ee5", "whatever 

















如 果 删 除了 茶 个 标签 





范围 的 所 有 标签 《例如 ， 删 





数据 分 发 到 任何 地 方 
































除了 标签 为 high 的 分 片 标签 )， 均 衡器 不 会 再 将 


























， 因 为 没有 可 的 位 置 。 所 











有 数据 仍 可 读 可 写 ， 但 不 会 被 迁移 到 其 他 位 置 ， 
除非 修改 标签 或 者 标签 范围 。 




















不 存在 用 于 删除 标签 范 转 

















甫 助 函 数 ， 但 可 手动 
































HR. Pay Hn ie E 
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， 可 通过 mongos 访 问 








config.tags 命 名 空 
息 保 存在 分 片 文档 "t 
config.shards 命 名 空 








间 。 类 似 地 ， 分 片 的 标签 信 
ags" 字 段 下 的 
间 。 如 分 片 文档 中 没 














15.5.2 ”手动 分 片 














有 "tags "字段 ， 则 该 分 片 就 不 存在 标签 。 





有 时 候 ， 对 于 复杂 的 需求 或 是 特殊 的 情况 ， 我 们 
可 能 希望 对 集群 的 数据 分 发 拥有 绝对 控制 权 。 如 





















































果 不 希 望 数据 被 自动 分 发 ， 可 关闭 均衡 器 ， 使 
jmoveChunk 命 令 手 动 对 数据 进行 迁移 。 











要 关闭 均衡 器 ， 可 连接 到 一 个 mongos (任何 
mongos 都 可 以 ) ， 然 后 使 用 以 下 命令 更 新 
config.settings 命 名 空间 : 
































> db.settings.update({"_id" : "balancer"}, 


























注意 ， 这 是 一 个 upsert 操 作 ， 如 果 均 衡器 设置 不 

存在 ， 则 会 自动 创建 一 个 。 

如 正在 进行 迁移 ， 则 该 设置 要 等 到 当前 迁移 完成 
之 后 才 会 生效 。 然 而 ， 一 旦 当前 迁移 完成 了 ， 均 
器 就 不 会 再 做 数据 移动 了 。 


只 要 均衡 器 被 关闭 ， 就 可 以 手动 做 数据 迁移 了 
《如 有 必要 的 话 ) 。 首 先 ， 查 看 config.chunks 找 出 
每 个 块 的 分 发 位 置 : 


> db.chunks.find() 


































































































EE 

























































































现在 ， 使 用 moveChunk 命 令 将 块 迁 移 到 其 他 分 
片 。 指 定 需 被 迁移 块 的 下 边界 值 和 目标 分 片 的 名 
称 : 


> sh.moveChunk("test.manual.stuff", 
... {user id: NumberLong("-184467440737095 
{ "millis" : 4079, "ok" : 1 } 





























然而 ， 除 非 遇 到 
MongoDB 的 自动 分 片 ， 而 非 手动 进行 分 



































最 后 得 到 一 个 扩 


























们 所 期 望 的 ) ， 


特殊 情 


况 ， 否 则 都 应 使 用 




















那么 大 


部 分 数据 可 









































Ho WR 


有 一 个 热点 的 分 片 这 并 非 是 我 


能 都 将 出 现在 





尤其 不 要 在 均衡 器 开局 的 情况 下 手动 做 一 些 不 寻 
常 的 分 有 发。 如果 均衡 器 检测 到 一 
则 会 对 调整 过 的 数据 进 
再 次 处 于 均衡 状态 。 如 





























些 不 均衡 的 块 ， 














行 重新 分 发 ， 以 便 让 集合 
































块 分 发 ， 应 使 
术 。 


和 上 一 小 节 


Die 








ow BAE BS 


过 的 分 片 标签 技 
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第 16 章 “分 片 管理 


对 数据 库 管 理 员 来 说 ， 分 片 集群 是 最 困难 的 部 署 
类 型 。 本 章 我 们 将 学 习 在 集群 上 执行 管理 任务 的 
方方面面 ， 内 容 包 括 : 


。 检查 集群 状态 : 集群 有 哪些 成 员 ? 数据 保存 
在 哪里 ? 哪些 连接 是 打开 的 ? 

。 如何 添加 、 删 除 和 修改 集群 的 成 员 ; 

。 管理 数据 移动 和 手动 移动 数据 。 


161 检查 集群 状态 


有 一 些 辅助 函数 可 用 于 找 出 数据 保存 位 置 、 所 在 
分 片 ， 以 及 集群 正在 进行 的 操作 。 




















































































































































































































16.1.1 使 用 sh.status 查 看 集群 摘要 信息 
使 用 sh.status() 可 查看 分 片 、 数 据 









































库 
合 的 摘要 信息 。 MARIAE, 则 该 命令 会 
打印 出 每 个 块 的 保存 位 置 。 否 则 它 只 会 简单 地 给 

















出 集合 的 片 键 ， 以 及 每 个 分 片 的 块 数 : 





> sh.status() 
--- Sharding Status --- 
sharding version: { "_id" : 1, "version" 


shards : 





{ "_id" "shardeeee", "host" : "local 
"tags" [ "USPS" , "Apple" ] } 
{ "_id" "shardeeei", "host" : “local 
{ "_id" "shardeee2", "host" "local 
databases: 
{ "_id" "admin", "partitioned" : fal 
{ "_id" "test", "partitioned" : true 
test.foo 
shard key: { "x" : 1, "y" : 1} 
chunks: 
shard6666 4 
shard6662 4 
shard6661 4 
{ "x" : { $minkKey : 1 }, "y" : { $m 
{ "x" : ©, "y" : 10000 } on: s 
{ "x" : @, "y" : 10000 } -->> { "x" 
on : Shard6662 
{ "x" : 12208, "y" : -2208 } -->> { 
on : shard@eee 
{ "x" : 24123, "y" : -14123 } -->> 
on : Shard6662 
{ "x" : 39467, "y" : -29467 } -->> 
on : shard6666 
{ "x" : 51382, "y" : -41382 } -->> 
on : Shard6662 
{ "x" : 64897, "y" : -54897 } -->> 
on : shard6666 
{ "x" : 76812, "y" : -66812 } -->> 








on : shard6662 


{ "x" : 92793, "y" : -82793 } -->> 
on : shard6661 

{ "x" : 119599, "y" : -109599 } --> 
on : shard6661 

{ "x" : 147099, "y" : -137099 } --> 
on : shard6661 

{ "x" : 173932, "y" : -163932 } --> 


{ "x" : { $maxKey : 1 }, "y" 
test.ips 
shard key: { "ip" : 1 } 
chunks: 
shard6666 2 
shard6662 3 
shard6661 3 


{ "ip" : { $minkey : 1} } -->> { " 
on : shardeeee 

{ "ip" : "002.075.101.096" } -->> { 
on : shard6662 

{ "ip" : "022.089.076.022" } -->> { 
on : shard6662 

{ "ip" : "@38.041.058.074" } -->> { 
on : shard6662 

{ "ip" : "055.081.104.118" } -->> { 
on : shard6666 

{ "ip" : "072.034.009.012" } -->> { 
on : shard6661 

{ "ip" : "090.118.120.031" } -->> { 


on : shard6661 





{ "ip" : "127.126.116.125" } -->> { 
on : shard6661 


tag: Apple { "ip" : "017.000.000. 
tag: USPS { "ip" : "056.000.000.0 
{ "_id" : "test2", "partitioned" : fal 





块 的 数量 较 多 时 ，sh.status() 命 令 会 概述 块 的 
状态 ， 而 非 打 印 出 每 个 块 的 相关 信息 。 如 需 查 看 
所 有 的 块 ， 可 使 用 sh.status(true) 命 令 

(true 参 数 要 求 sh .status() 命 令 打 印 出 尽 可 能 
详尽 的 信息 ) 。 


sh.status() 显 示 的 所 有 信息 都 来 自 config 数 # 
































HI 














运行 sh.status() 命 令 ， 使 MapReduce 获 取 这 一 
数据 ， 因 此 ， 如 果 启 动 数据 库 时 指定 了 -- 

noscripting 选 项 ， 则 无 法 运行 sh .status() 命 
令 。 
























































16.1.2 检查 配置 信息 

















集群 相关 的 所 有 配置 信息 都 保存 在 配置 服务 器 上 
config 数 据 库 的 集合 中 。 可 直接 访问 该 数据 库 ， 
不 过 shell 提 供 了 rei 并 通过 这 些 函数 
获取 更 适 于 阅读 的 信息 。 不 过 ， 可 始终 通过 直接 









































































































































查询 config 数 据 库 的 方式 ， 获 取 集 群 的 元 数据 。 


+S... 要 直接 连接 到 配置 服务 器 ， 


以 防 配置 服务 器 数据 被 不 小 心 修改 或 删除 。 应 
先 连接 到 mongos， 然 后 通过 config 数 据 库 来 查 
询 相 关 信息 ， 方 法 与 查询 其 他 数据 库 一 样 : 

























































































mongos> use config 





























如 果 通 过 mongos 操 作 配 置 数 据 ( 而 不 是 直接 连 
接 到 配置 服务 器 ) ，mongos 会 保证 将 修改 同步 
到 所 有 配置 服务 器 ， 也 会 防止 危险 操作 的 发 

生 ， 如 意外 删除 config 数 据 库 等 。 


总 的 来 说 ， 不 应 直接 修改 confg 数 据 库 的 任何 数 
据 《〈 例 外 情况 下 面 会 提 到 ) 。 如 果 确 实 修改 了 某 
些 数据 ， 通 常 需要 重启 所 有 的 mongos 服 务 器 ， 才 
能 看 到 效果 。 


config 数 据 库 中 有 一 些 
合 的 内 容 和 使 用 方法 。 
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1. config.shards 


















































shards 集 合 跟踪 记录 集群 内 所 有 分 片 的 信息 。 
shards 集 合 中 的 一 个 典型 文档 结构 如 下 : 
> db.shards.findOne() 
{ 
"_id" : "spock", 
"host" : "spock/server-1:27017,server- 
"tags" : [ 
"us-east", 
"64gb mem", 
"cpu3" 
] 
} 


















































分 片 的 "_id" 来 自 于 副本 集 的 名 称 ， 所 以 集群 ! 
的 每 个 副本 集 名 称 都 必须 是 唯一 的 。 


更 新 副本 集 配 置 的 时 候 〈 比 如 添加 或 删除 成 
员 ) ，host 字 段 会 自动 更 新 。 


Y 
















































































2. onfig.databases 














databases 集 合 跟踪 记录 集群 中 所 有 数据 库 的 信 
息 ， 不 管 数据 库 有 没有 被 分 片 : 


> db.databases.find() 
{ "_id" : "admin", "partitioned" : false, 

























































































{ "id" : "testi", "partitioned" : true, " 
{ "_id" : "test2", "partitioned" : false, 
如 果 在 数据 库 上 执行 过 enableSharding， 则 此 
Abh" partitioned" ZPUE 

是 true。"primary" 是 “ 主 数据 库 ”(home 

base) 。 数 据 库 的 所 有 新 集合 均 默 认 被 创建 在 数 
据 库 的 主 分 片上 。 








3. config.collections 





















































collections 集 合 跟踪 记录 所 有 分 片 集合 的 信息 《〈 非 
分 片 集合 信息 除外 ) 。 其 中 的 文档 结构 如 下 : 
> db.collections.findone() 
{ 
"id" : "test.foo", 
"lastmod" : ISODate("1970-0@1-16T17:53: 
"dropped" : false, 
"key" : { "hy" : É; "y" : 1 h 
"unique" : true 
} 
下 面 是 一 些 重 要 字段 。 














片 键 。 本 例 中 指 由 x 和 y 组 成 的 复合 片 键 。 


e unique 
表明 片 键 是 一 个 唯一 索引 。 该 字段 只 有 当 值 
为 true 时 才 会 出 现 〈 表 明 片 键 是 唯一 的 ) 。 
片 键 默认 不 是 唯一 的 。 
































4. config.chunks 


chunks 集 合 记 录 有 集合 中 所 有 块 的 信息 。chunks 集 
合 中 的 一 个 典型 文档 结构 如 下 所 示 : 












































{ 
"_id" : "test. hashy- user_id_-103430811 
"Iastmod" : { "t" : 5000, "i" : 50 }, 
"lastmodEpoch" : ObjectId("56f5c648866 
"ns" : "test.hashy", 
"min" : { "user_id" : NumberLong("-103 
"max" : { "user_id" : NumberLong("-732 
"shard" : "test-rs2" 

} 





























下 面 这 些 字段 最 为 有 用 。 








e id 
块 的 唯一 标识 符 。 该 标识 符 通 常 
间 、 片 键 和 块 的 下 边界 值 组 成 。 






































S 
块 所 属 的 集合 名 称 。 





e min 
块 范围 的 最 小 值 (包含 )。 




















e max 


块 范围 的 最 大 值 (不 包含 ) 。 

















e shard 


块 所 属 的 分 片 。 


这 里 的 lastmod 和 1astmodEpoch 字 段 用 于 记录 

块 的 版 本 。 例 如 ， 如 一 个 名 为 foo.bar-_id-1 的 
块 被 拆 分 为 两 个 块 ， 原 本 的 foo.bar-_id-1 会 成 
为 一 个 较 小 的 新 块 ， 我 们 需要 一 种 方式 来 区 别 该 
块 与 之 前 的 块 。 因 此 ， 我 们 用 t 和 i 字段 表示 块 的 
E (major) 版 本 和 副 (minor) WE: 主 版 本 会 
在 块 被 迁移 至 新 的 分 片 时 发 生 改 变 ， 副 版 本 会 在 
块 被 拆 分 时 发 生 改变 。 


sh.status() 获 取 的 大 部 分 信息 都 来 自 于 





































































































config.chunks 集 合 。 


5. config.changelog 














changelog 集 合 可 用 于 跟踪 记录 集群 的 操作 ， 因 为 
该 集合 会 记录 所 有 的 拆 分 和 迁移 操作 。 


拆 分 记录 的 文档 结构 如 下 : 























{ 
Sord” "router1-2013-02-09T18:08:12-5 
"server" : "spock-@1", 
"clientAddr" : "10.3.1.71:62813", 
"time" : ISODate("2013-02-09T18:08:12. 
"what" "split", 
"ns" : "test.foo", 
"details" : { 
"before" : { 
"min" : { "x" : { $minKey : 1 
"max" : { "x" : { $maxKey : 1 
"lastmod" : Timestamp(1000, ©) 
"lastmodEpoch" : 0bjectId("666 
}, 
"left" : { 


min" : { "x" : { $minKey : 1 
"max" : { "x" : ©, "y" : 10000 
"lastmod" : Timestamp(10@0, 1) 
"“lastmodEpoch" : ObjectId("9ee 





min" : { "x" : ©, "y" : 10000 
"max" : { "x" : { $maxKey : 1 
"lastmod" : Timestamp(10@0, 2) 
"lastmodEpoch" : 0bjectId("666 


} 





} 


从 details 字 段 中 可 以 看 到 文档 在 拆 分 前 和 拆 分 
后 的 内 容 。 


这 里 显示 的 是 集合 第 一 个 块 被 拆 分 后 的 情景 。 注 
意 ， 每 个 新 块 的 副 版 本 都 发 生 了 增长 : 新 块 的 
1astmod 分 别 是 Timestamp(1666，1) 和 
Timestamp(10@@, 2). 


数据 迁移 的 操作 比较 复杂 ， 每 次 迁移 实际 上 会 创 
建 4 个 独立 的 changelog 文 档 : 一 条 是 迁移 开始 时 
的 状态 ， 一 条 是 from 分 片 的 文档 ， 一 条 是 to 分 片 
的 文档 ， 还 有 一 条 是 迁移 完成 时 的 状态 。 中 间 的 
两 个 文档 比较 有 参考 价值 ， 因 为 可 从 中 看 出 每 一 
步 操 作 耗 时 多 久 。 这 样 就 可 得 知 ， 造 成 迁移 瓶颈 
的 到 底 是 磁盘 、 网 络 还 是 其 他 什么 原因 了 。 


列 如 ，from 分 片 的 文档 结构 如 下 : 










































































































































































{ 
"_id" "router1-2013-02-09T18:15:14-5 
"server" "spock-01", 
"clientAddr" "10.3.1.71:27017", 
"time" : ISODate("2013-02-09T18:15:14. 
"what" "moveChunk.to", 
"ns" : "test.foo", 
"details" : { 
"min" : { "x" : 24123, "y" : -1412 
"max" : { "x" : 39467, "y" : -2946 
"step1 of 5" ð, 
"step2 of 5" : 6， 
"step3 of 5" : 900, 
"step4 of 5" : 6， 
"step5 of 5" 142 
} 
}; 
details 字 段 中 的 每 一 步 表 示 的 都 是 时 
间 ，stepN of 5 信息 以 毫秒 为 单位 ， 显 示 了 步 
又 的 耗 时 长 短 。 当 from 分 片 收 到 mongos 发 来 的 


moveChunk 命 令 时 ， 它 会 : 





1. 检查 命令 的 参数 ; 
2, 











入 迁移 过 程 ; 
. 尝试 连接 到 to 分 片 ; 

















向 配置 服务 器 申请 获得 一 个 分 布 锁 ， 以 便 进 


























4. 数据 复制 ， 这 是 整个 过 程 的 “临界 


IX” (critical section) ; 























5. 与 to 分 片 和 配置 服务 器 一 起 确认 迁移 是 否 


功 完成 。 




















z 


成 





注意 ，step4 of 5 中 的 to 和 from 分 片 间 进行 的 


是 直接 通信 : 每 个 分 片 都 是 直接 连接 到 男 一 个 分 
片 和 配置 服务 器 上 ， 以 进行 迁移 。 如 果 from 分 片 
在 迁移 过 程 的 最 后 一 步 出 现 短暂 的 网 络 连接 问 
题 ， 它 可 能 会 处 于 无 法 撤销 迁移 操作 也 无 法 继续 
进行 下 去 的 状态 。 在 这 种 情况 下 ，mongod 会 关 
































































































































闭 。 
to 分 片 的 changloe 文 档 与 from 分 片 类 似 ， 但 步骤 
有 些许 不 同 : 
{ 
"_id" : "router1-2013-02-09T18:15:14-5 
"server" : "spock-@1", 
"clientAddr" : "10.3.1.71:62813", 
"time" : ISODate("2013-02-09T18:15:14. 
"what" : "moveChunk.from", 
"ns" : "test.foo", 
"details" : { 


"step1 of 6" : 6， 





"min" : { "x" : 24123, "y" : 
"max" : { "x" : 39467, "y" : 


-141 
-294 





"step2 of 6" : 2, 
"step3 of 6" : 33, 
"step4 of 6" : 1032, 
"step5 of 6" : 12, 
"step6 of 6" : 0 

} 








} 


当 to 分 片 收 到 from 分 片 发 来 的 命令 时 ， 它 会 执行 
如 下 操作 。 


1. 迁移 索引 。 如 果 该 分 片 不 包含 任何 来 自 迁 移 
集合 的 块 ， 则 需 知道 有 哪些 字段 上 建立 过 索 
引 。 如 果 在 此 之 前 to 分 片 已 有 来 自 于 该 集合 
的 块 ， 则 可 忽略 此 步骤 。 
2. 删除 块 范围 内 已 存在 的 任何 数据 。 之 前 失败 
的 迁移 “如 果 有 的 话 〉 可 能 会 留 有 数据 残 
余 ， 或 者 是 正 处 于 恢复 过 程 当中 ， 此 时 我 们 
不 希望 残留 数据 与 新 数据 混杂 在 一 起 。 
3. 将 块 中 的 所 有 文档 复制 到 to 分 片 。 
4. 复制 期 间 ， 在 to 分 片上 重新 执行 曾 在 这 些 文 
档 上 执行 过 的 操作 。 
5. 等 待 to 分 片 将 新 迁移 过 来 的 数据 复制 到 集群 
的 大 多 数 服务 器 上 。 
6. 修改 块 的 元 数据 以 完成 迁移 过 程 ， 表 明 数 据 
已 被 成 功 迁 移 到 to 分 片上 o 
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6. config.tags 














该 集合 的 创建 是 在 为 系统 配置 分 片 标签 时 发 4 
的 。 每 个 标签 都 与 一 个 块 范围 相关 联 : 


H 






































> db.tags.find() 
{ 
"id" : { 
"ns" "test.ips", 
"min" : {"ip" : "056.000.000.000" } 
js 
"ns" "test.ips", 
"min" : {"ip" : "056.000.000.000"}, 
"max" : {"ip" : "@57.000.000.000"}, 
"tag" : "USPS" 
} 
{ 
"id": { 
"ns" "test.ips", 
"min" : {"ip" : "017.000.000.000" } 
js 
"ns" "test.ips", 
"min" : {"ip" : "017.000.000.000"}, 
"max" : {"ip" : "018.000.000.000"}, 
"tag" "Apple" 
} 





7. config.settings 





集合 含有 当前 的 均衡 器 设置 和 块 大 小 的 文档 信 
。 通 过 修改 该 集合 的 文档 ， 可 开启 或 关闭 均衡 
器 ， 也 可 以 修改 块 的 大 小 。 注 意 ， 应 总 是 连接 到 
mongos 修 改 该 集合 的 值 ， 而 不 应 直接 3 连接 到 配置 
服务 器 进行 修改 。 


16.2 ”查看 网 络 连 接 
集群 的 各 组 成 部 分 间 存 在 大 量 的 连接 。 本 节 我 们 


将 学 习 与 分 片 相关 的 连接 信息 。 网 络 信息 会 在 第 
23 章 详细 介绍 。 
































CI Xe 






























































让 





























16.2.1 查看 连接 统计 























可 使 用 connPoolStats 命 令 ， 查 看 mongos 和 
mongod 之 间 的 连接 信息 ， 并 可 得 知 服务 器 上 打开 
的 所 有 连接 : 


























> db.adminCommand({"connPoolStats" : 1}) 
{ 
"createdByType": { 
"sync": 857, 
"set": 4 


3 
"numDBClientConnection": 35, 
"numAScopedConnection": @, 








"hosts": { 

"config-01:10005, config-02:10005,c 
"created": 857, 
"available": 2 

}, 

"spock/spock-@1: 10005, spock-02:100 
"created": 4, 
"available": 1 


} 
}s 
"totalAvailable": 3, 
"totalCreated": 861, 
"ok": 1 








} 








形 如 "host1，host2，host3" 的 主机 名 是 来 自 配 
置 服务 器 的 连接 ， 也 就 是 用 于 “同步 ”的 连接 。 形 
如 "name/host1，host2,...,hostN" 的 主机 是 
来 自分 片 的 连接 。available 的 值 表 明 当 前 实例 
的 连接 池 中 有 多 少 可 用 连接 。 


注意 ， 只 有 在 分 片 内 的 mongos 和 mongod 上 运行 这 
个 命令 才 会 有 效 。 


在 一 个 分 片上 执行 connPoolstats， 输 出 信息 中 
可 看 到 该 分 片 与 其 他 分 片 间 的 连接 ， 包 括 连接 到 
其 他 分 片 做 数据 迁移 的 连接 。 分 片 的 主 连接 会 直 
















































































































































































接连 接 到 男 一 分 片 的 主 连 接 上 ， 然 后 从 目标 分 片 
吸取 数据 。 

进行 迁移 时 ， 分 片 会 建立 一 

eet (该 进程 用 于 监控 副本 集 


的 健康 状况 ) ， 上 月 
健康 状况 。 
































于 mongod 不 会 销量 





日 于 追踪 


oy FY, 

















以 有 时 会 在 











副本 集 的 














成 员 的 信息 
成 任何 影响 。 





H| 
H 车 


16.2.2 ”限制 连 





uz E 


十 





当 有 客 


户 端 











接 数 量 


接 到 mo 
连接 ， 该 连接 应 至 少 


mongos 





客户 端 请 求 发 送 给 分 片 。 


日 志 中 看 到 
。 这 是 很 正常 的 ， 不 会 对 应 用 











记录 迁移 男 一 端 分 片 的 


股 这 个 监控 器 ， 所 
其 
































时 ，mongos 会 创建 一 
连接 到 一 个 分 片上 ， sr 























大 














此 ， 每 个 连接 到 





mongos 的 客户 端 
到 分 片 的 连接 。 























如 果 
连接 ， 甚 至 
多 允许 20 00 

















ER, MA 
到 分 片 的 连 





接 ! 


连接 者 


有 多 个 mongos 进 程 ， 可 
超出 分 片 的 处 理 
0 个 连接 Cmongod 也 是 如 此 ) 。 
有 5 个 mongos 进 程 ， 每 个 mongos 有 10 000 个 客 
这 些 mongos 可 能 会 试 





ab 
能 会 




















会 至 少 产 和 





个 从 mongos 





创建 出 非常 多 的 

















能 


个 mongos 最 
如 果 


户 端 














K] 








创建 50 000^ 





为 防 





止 这 种 情况 的 发 生 ， 可 在 mongos 的 命令 行 配 
中 使 用 maxConns 选 项 ， 这 样 可 以 限制 mongos 
































能 够 创建 的 连接 数量 。 












































能 够 处 理 的 来 自 单 


maxConns=20 000-(mongos 进 程 的 数量 x3)-( 每 个 











副本 集 的 成 员 数 量 x3)-( 其 他 /mongos 进 程 的 数量 ) 





可 使 用 下 列 公式 计算 分 片 
mongos 的 连接 数量 : 















































以 下 为 公式 的 相关 说 明 。 


e (mongos 进 程 的 数量 x3) 
每 个 mongos 会 为 每 个 mongod 创 建 3 个 连接 : 
一 个 用 于 转发 客户 端 请 求 ， 一 个 用 于 追踪 错 




















误 信 息 ， 即 
listener) ， 





(每 个 副本 集 的 成 员 数 量 x3) 
主 节 点 会 与 每 个 备份 节点 创建 一 个 连接 ， 而 








与 


口 














监听 器 Cwriteback 





一 个 用 于 监控 副本 集 状 态 。 



































每 个 备份 节点 会 与 主 节 点 创建 两 个 连接 ， 基 























此 总 共 是 3 个 连接 。 











(其 他 /mongosj 
这 里 的 其 他 指 





进程 的 数量 ) 
其 他 可 能 连接 到 mongod 的 进程 


























连接 (管理 


O 
ia} 





数量 ， 这 种 连接 包括 MMS 代理 、shell 的 直接 
其 





j ) ， 或 者 是 迁移 时 连接 到 3 





他 分 片 的 连接 。 









































注意 ，maxConns 只 会 阻止 mongos 创 建 


























maxConns 数 量 的 连接 :但 并 不 会 帮助 处 理 连接 


耗 尽 的 问题 。 连 接 耗 尽 时 ， 请 求 会 发 生 阳 塞 ， 和 全 
止 应 用 程序 使 
的 连接 ， 尤 其 是 在 mongos 


Z; 





























超过 maxConns 数 量 日 
进程 数量 不 断 增加 时 。 


MongoDB 实 例 在 安全 退出 时 ， 会 如 





待 某 些 连接 被 释放 。 因 此 ， 必 须 防 



















































































即 收 到 套 接 字 错 误 
刷新 连接 。 但 是 ， 妇 

















FE 终止 运行 之 前 
关闭 所 有 连接 。 已 经 连接 到 MongoDB 的 成 员 会 立 
(socket error) ， 并 能 够 重新 
[I 果 MongoDB 实 例 由 于 断 电 、 


骨 溃 或 者 网 络 问题 突然 离线 ， 那 些 已 经 打开 的 套 


接 字 很 可 能 没有 被 关闭 。 
的 其 他 服务 器 很 可 

















话 ) 。 


此 时 该 MongoDB 实 例 再 次 上 线 

















行 操作 时 ， 就 会 遇 到 错误 ， 继 而 届 


在 这 种 情况 下 ， 集 群 内 
能 会 认为 这 个 MongoDB 实 例 仍 
在 有 效 运转 ， 但 是 当 试 图 在 该 MongoDB 实 例 上 执 























= 





新 连接 (ane 





























连接 数量 较 少 时 ， 




















ua 











每 个 连接 都 需要 经 历 被 尝试 、 检 测 失败 ， 并 重新 
此 过 程 中 会 得 到 大 量 











建立 连接 的 过 程 ， 


运转 正常 的 


j 快速 检测 到 某 台 MongoDB 实 
网 是 否 已 离线 。 但 是 ， 当 有 成 了 





F 上 万 个 连接 时 ， 





> 
的 错误 。 












































在 出 现 大 量 重新 连接 时 ， 除 了 习 











他 特殊 有 效 的 方法 。 








TE 





Ey 没有 其 











16.3 ”服务 器 管理 


随 着 集群 的 增长 ， 我 们 可 能 需要 增加 集群 容量 或 
者 是 修改 集群 配置 。 本 节 我 们 将 学 习 向 集群 添加 








服务 器 以 及 从 集群 删除 服务 器 的 方法 。 


16.3.1 





配置 服务 ，mongos 即 可 立即 与 客户 端 























添加 服务 器 





























可 随时 向 集群 中 添加 新 的 mongos。 。 只 要 保证 在 








mongos 的 --configdb 选 项 中 指定 了 一 组 正确 的 
































如 14 章 所 示 ， 可 使 用 addshard 命 令 ， 
加 新 分 片 。 
16.3.2 ”修改 分 片 的 服务 器 


建立 连接 。 





向 集群 添 


使 用 分 片 集群 时 ， 我 们 可 能 会 希望 修改 某 单独 分 
片 的 服务 器 。 要 修改 分 片 的 成 员 ， 需 直接 连接 到 








对 副本 集 进行 重新 配置 。 集 群 配置 会 E 

















EE 服务 器 上 (而 不 是 通过 mongos )， 然 后 
































动 检测 更 



























































改 ， 并 将 其 更 新 到 config.shards 上 。 不 要 手动 修改 





config.shards 。 


只 有 在 使 有 





























有 单机 服务 器 作为 分 片 ， 而 不 是 使 用 吕 





hiag 





本 集 作 为 分 片 时 ， 才 需 手动 修改 config.shards。 
将 单机 服务 器 分 片 修改 为 副本 集 分 片 
单 的 方式 是 添加 一 个 新 的 空 副 本 集 分 片 ， 然 


最 简 














后 移 


如 果 
过 程 会 

















1. 
2. 


3. 











除 单机 服务 器 分 片 〈 参 见 16.3.3 节 ) 。 
希望 把 单机 服务 器 分 片 转换 为 副本 集 分 片 ， 








复杂 得 多 ， 而 且 需 要 停机 。 
停止 向 系统 发 送 请 求 。 











关闭 单机 服务 器 (这 里 称 其 为 server-1) 和 所 


有 的 mongos 进 程 。 











以 副本 集 模式 重启 server-1 (使 用 --replSet 








选项 ) 。 























进行 初始 化 。 












































config.shards 中 将 分 片 名 称 蔡 换 
为 setName/server-1:27617 的 











连接 到 server-1， 将 其 作为 一 个 单 成 员 副 本 集 








. 连接 到 配置 服务 器 ， 蔡 换 该 分 片 的 入 口 ， 在 














Bak. BER 


三 个 配置 服务 器 都 拥有 相同 的 配置 信息 。 手 























动 修改 配置 服务 器 是 有 风险 的 ! 























可 在 每 个 配置 服务 器 上 执行 dbhash 命 令 ， 以 











确保 配置 信息 相同 : 























> db.runCommand({"dbhash" : 1}) 














这 样 可 以 得 到 每 个 集合 的 MD5 散 列 值 。 不 同 
配置 服务 器 上 ，config 数 据 库 的 集合 可 能 会 
有 所 不 同 ， 但 config.shards 应 始终 保持 一 致 。 


6. 重启 所 有 mongos 进 程 。 它 们 会 在 启动 时 从 配 
IN 






























































服务 器 读 取 分 片 数据 ， 然 后 将 副本 集 当 作 
分 片 对 待 。 
7. 重启 所 有 分 片 的 主 服务 器 ， 刷 新 其 配置 数 


8， 再 次 向 系统 发 送 请 求 。 
可 server-1 副 本 集中 添加 新 成 员 。 


这 一 过 程 非常 复杂 ， 而 且 很 容易 出 错 ， 因 此 不 建 
议 使 用 。 应 尽 可 能 地 将 空 的 副本 集 作为 新 的 分 片 
添加 到 集群 中 ， 数 据 迁 移 的 事情 交 给 集群 去 做 就 
好 了 。 















































































































































16.3.3 ”删除 分 片 


























通常 来 说 ， A aa 如 果 经 常 在 
集群 中 添加 和 删除 分 片 ， 会 给 系统 带 来 很 多 不 必 
要 的 压力 。 如 果 向 集群 中 添加 了 过 多 的 分 片 ， 最 
好 是 什么 也 不 做 ， 系 统 早 晚会 用 到 这 些 分 片 ， 而 


















































不 应 该 将 多 余 的 分 斤 删 掉 ， 等 以 后 需要 的 时 候 再 
将 其 重新 添加 到 集群 中 。 不 过 ， 在 必要 的 情况 
下 ， 是 可 以 删除 分 片 的 。 


于 先 保 证 均衡 器 是 开启 的 。 在 排出 数据 

(draining) 的 过 程 中 ， 均 衡器 会 负责 将 待 删除 分 
片 的 数据 迁移 至 其 他 分 片 。 执 行 removeShard 命 
令 ， 开 始 排 出 数据 。removeShard 将 待 删 除 分 片 
的 名 称 作为 参数 ， 然 后 将 该 分 片上 的 所 有 块 都 移 
至 其 他 分 片上 : 
















































































> db.adminCommand({"removeShard" : "test-r 
{ 
"msg" : "draining started successfully 
"state" : "started", 
"shard" : "test-rs3", 
"note" : "you need to drop or movePrim 
"dbsToMove" : [ 





























如 果 分 片上 的 块 较 多 ， 或 者 有 较 大 的 块 需要 移 
动 ， 排 出 数据 的 过 程 可 能 会 耗 时 更 长 。 如 果 存 在 























特大 块 Gumbo chunk， 参 见 16.4.4 节 ) ， 可 能 需 
临时 提高 其 他 分 片 的 块 大 小 ， 以 便 能 够 将 特大 块 
迁移 到 其 他 分 片 。 


如 需 查 看 哪些 块 己 完成 迁移 ， 可 再 次 执 
行 removeShard 命 令 ， 查 看 当前 状态 : 



























































> db.adminCommand({"removeShard" : "test-r 
{ 

"msg" : "draining ongoing", 

"state" : "ongoing", 

"remaining" : { 


"chunks" : NumberLong(5), 
"dbs" : NumberLong(@) 











Į 
"ok" : 1 
} 
在 一 个 处 于 排出 数据 过 程 的 分 片上 ， 可 执 








行 removeShard 任 意 多 次 。 























块 在 移动 前 可 能 需要 被 拆 分 ， 所 以 有 可 能 会 看 到 
系统 中 的 块 数量 在 排出 数据 时 发 生 了 增长 。 假 设 
有 一 个 拥有 5 个 分 片 的 集群 ， 块 的 分 布 如 下 : 
test-rs6 10 


test-rs1 10 
test-rs2 10 






































test-rs3 11 
test-rs4 11 


























该 集群 共有 52 个 块 。 如 果 删 除 test-rs3 分 片 ， 





























最 终 的 结果 可 能 会 是 : 








test-rs6 15 
test-rs1 15 
test-rs2 15 
test-rs4 15 





集 


AIN 





群 现在 拥有 60 个 块 ，] 





其 中 18 个 来 自 test-rs3 


分 片 ( 原 本 有 11 个 ， 还 有 7 个 是 在 排出 数据 的 过 





所 有 的 块 都 完成 迁移 后 ， 如 果 仍 有 数 扩 
片 作为 主 分 片 ， 需 在 删除 分 片 前 将 这 些 数 据 库 移 


除 掉 。removeShard 命 令 的 输 昌 











程 中 创建 的 ) 。 








结果 可 能 如 下 : 


居 库 将 该 分 








> db.adminCommand({"removeShard" 


{ 





"msg" : "draining ongoing", 
"state" : "ongoing", 
"remaining" : { 


"chunks" : NumberLong(@), 
"dbs" : NumberLong(3) 


: "test-r 





: "you need to drop or movePrim 












































"“dbsToMove" : [ 
"blog", 
"music", 
"prod" 
]， 
"ok" : 1 
} 
为 完成 分 片 的 删除 ， 需 先 使 用 movePrimary 命 令 
将 这 些 数据 库 移 走 : 
> db.adminCommand({"movePrimary" "blog", 
{ 
"primary ”: "test-rs4:test-rs4/ubuntu 
"ok" : 1 
} 


然后 再 次 执行 removeShard 命 令 : 























> db.adminCommand({"removeShard" "test-r 
{ 
"msg" "removeshard completed success 
"state" "completed", 
"shard" : "test-rs3", 
'ok" : 1 
} 


























最 后 一 步 不 是 必需 的 ， 但 可 确保 已 确实 完成 了 分 























片 的 删除 。 如 果 不 存 在 将 
据 库 ， 则 块 的 迁移 完成 后 
功 的 输出 信息 。 









































16.3.4 {5 








注意 ， 如 果 
停止 这 一 过 





Fi 
[ 程 了 。 














改 配置 服务 器 




















该 分 片 作为 主 分 片 








H 





的 数 


即 可 看 到 分 片 删除 成 





+ 开始 排出 数据 ， 就 没有 内 置办 法 


修改 配置 服务 器 是 非常 困难 的 ， 而 且 有 风险 ， 














Œp 


常 还 需要 停机 。 





做 好 备份 。 














在 运行 期 间 ， 所 有 mongos 进 程 
项 值 都 必须 相同 。 因 此 ， 
先 必须 关闭 












































注意 ， 修 改 配 置 服务 器 前 



































所 有 的 mongos 









































J, 




















通 
DA 


的 --configdb 选 
要 修改 配置 服务 器 ， 首 
































进程 (mongos 进 程 在 使 
] 旧 的 --configdb 参 数 时 ， 无 法 继续 保持 运行 








状态 ) ， 然 后 使 用 新 的 - -configdb 参 数 重启 所 





有 mongos 进 程 。 


例如 ， 将 一 
务 之 一 。 为 实现 此 操作 ， 


Imongos 进 程 、 








后 将 配置 服 




















区 








服务 器 上 


C 











台 配 置 服务 器 ] 














配置 服务 器 


省 至 三 台 是 最 党 


首先 应 关闭 所 有 
， 以 及 所 有 的 分 











JL 
的 





的 任 


然 
o FN 











务 器 的 数据 目 
S 台 配 置 











相同 的 数 扩 


=] 


ii 











录 复 制 到 两 台新 的 配置 









































服务 器 就 可 以 拥 























。 接 着 


























有 完全 


， 局 动 这 三 台 配 置 服务 








器 和 所 有 分 片 。 然 后 ， 将 - -configdb 选 项 指定 
为 这 三 台 配 置 服务 器 ， 最 后 重启 所 有 的 mongos 进 
程 。 


16.4 数据 均衡 
通常 来 说 ，MongoDB 会 自动 处 理 数据 均衡 。 本 节 


我 们 将 学 习 如 何 启用 和 禁用 自动 均衡 ， 以 及 如 何 
人 为 干涉 均衡 过 程 。 




















































































































16.4.1 均衡 器 




















在 执行 几乎 所 有 的 数据 库 管 理 操作 之 前 ， 都 应 先 
关闭 均衡 器 。 可 使 用 下 列 shell 辅 助 函 数 关 闭 均 衡 
AF: 


















































> sh.setBalancerState(false) 




















均衡 器 关闭 后 ， 系 统 则 不 会 再 进入 均衡 过 程 ， 但 
该 命令 并 不 能 立即 终 迁移 
过 程 通常 无 法 立即 停止 。 因 此 ， 应 检查 
config.locks 集 合 ， ae ee ae 


Ho. 































































































> db.locks.find({"_id" : "balancer"})["sta 
0 














此 处 的 0 表明 均衡 器 已 被 关闭 。 可 翻阅 “均衡 
器 ”一 节 查 看 均衡 器 状态 相关 内 容 。 


均衡 过 程 会 增加 系统 负载 ， 目 标 分 片 必须 查询 源 
分 片 块 中 的 所 有 文档 ， 将 文档 插入 
































目标 分 片 的 块 


















































中 ， 源 分 片 最 后 必须 删除 这 些 文档 。 
特殊 情况 下 ， 迁 移 会 导致 怕 


1. 使 用 热点 片 键 可 保证 定期 迁移 (因为 所 有 的 


新 块 都 是 创建 在 热点 上 的 ) 。 


力 处 理 源 源 不 断 写 入 到 热点 分 


2. 向 集群 中 添加 新 的 分 片 时 ， 均 衡器 会 试图 为 
该 分 片 写 入 数据 ， 从 而 触发 一 














程 。 








在 以 下 两 种 





Efe 








系统 必须 有 能 
片上 的 数据 。 

















系列 的 迁移 过 




















如 果 发 现 数据 迁移 过 程 影响 了 应 / 























程序 性 外 能 ， 可 














在 config.settings 集 合 中 为 数 # 



































点 到 4 点 间 发 生 ， 


窗口 。 执 行 下 列 更 新 语句 


居 均 衡 指定 一 个 时 间 
, 均衡 则 只 会 在 下 午 1 




















> db.settings.update({"_id 
. {"$set" : {"activeWindow" 
. true ) 


"balancer"}, 
: {"start" 








如 指定 了 均衡 时 间 窗 ， 贝 








| 应 对 


其 进行 

















以 确保 mongos 确 实 只 在 # 


肯定 的 


对 间 


严密 监控 ， 


内 做 均衡 。 


如 需 混 
































移 至 shardB 。 此 时 如 再 启 
30 个 块 (很 可 能 不 是 刚刚 的 30 块 
shardA， 以 均衡 两 个 分 片 扩 


为 防止 这 种 情况 发 生 























动 均衡 器 总 




















j 手 动 均衡 和 自动 均衡 ， 必 须 格 外 小 心 。 








是 根据 数据 集 








ERTL, MRS EBA 
如 ， 假 设 有 两 个 分 片 shardA 和 shardB， 每 个 分 片 
都 有 500 个 块 。 由 于 


ERHI 


的 当前 状态 来 决 
历史 状态 。 例 


shardA 上 的 写 请 求 比较 多 ， 


ERIAM TIAE, ARI 












































shardB 选 取 30 个 不 活跃 的 


两 个 分 片 间 就 不 会 存在 不 均衡 ， 





出 一 些 





作为 衡 
Ay RR 





BIR 
块 ， 


注意 ， 均 衡器 只 使 / 


E. 


里 


14h 














多 较 小 的 块 〈 但 总 数据 大 小 比 A 小 ) 


























有 的 块 数量 。 


， 可 在 启用 均衡 器 之 前 从 
块 移 至 shardA。 这 样 
均衡 器 也 不 会 进 





的 块 中 取出 30 个 


均衡 器 ， 则 会 立即 将 


) 从 shardB 移 至 


























的 移动 了 。 


男 外 ， 











也 可 在 shardA 上 拆 分 
以 实现 shardA 和 shardB 的 均衡 。 

















分 片 间 是 否 





均衡 和 





j 块 的 数量 ， 而 非 数 据 大 小 ， 








的 指标 。 




















A, WRA 


























有 几 个 较 大 的 数据 块 ， 而 B 分 片 拥 有 许 











， 那 么 均衡 





器 会 将 B 分 片 的 一 些 块 移 至 A 分 片 ， 从 而 实现 均 


16.4.2 ”修改 块 大 小 


块 中 的 文档 数量 可 能 为 0， 也 可 能 多 达 数 百 万 。 
通常 情况 下 ， 块 越 大 ， 迁 移 至 分 片 的 耗 时 就 越 
长 。 在 第 13 章 中 ， 我 们 使 用 的 是 1 MB 的 块 ， 所 以 
块 移 动 起 来 非常 容易 与 迅速 。 但 在 实际 系统 中 ， 
这 通常 是 不 现实 的 。MongoDB 需 要 做 大 量 非 必要 
的 工作 ， 才 能 将 分 片 大 小 维持 在 几 MB 以 内 。 块 
的 大 小 默认 为 64 MB， 这 个 大 小 的 块 既 易于 迁 
移 ， 又 不 会 导致 过 多 的 流失 。 


有 时 可 能 会 发 现 移动 64 MB 的 块 耗 时 过 长 。 可 通 
过 减 小 块 的 大 小 ， 提 高 迁移 速度 。 使 用 shell 连 接 
到 mongos， 然 后 修改 config.settings 集 合 ， 从 而 完 
成 块 大 小 的 修改 : 


















































pag 




































































> db.settings.findone() 


{ 
"id" : "chunksize", 
"value" : 64 
> db.settings.save({"_id" : "chunksize", " 











以 上 修改 操作 将 块 的 大 小 减 至 32 MB。 已 经 存在 
的 块 不 会 立即 发 生 改 变 ， 执 行 块 拆 分 操作 时 ， 这 
些 块 即 可 拆 分 成 32 MB 大 小 。mongos 进 程 会 自动 
加 载 新 的 块 大 小 。 


注意 ， 该 设置 的 有 效 范围 是 整个 集群 : 它 会 影响 



















































































所 有 集合 和 数据 库 。 因 此 ， 如 需 对 一 个 集合 使 用 
较 小 的 块 ， 而 对 另 一 集合 使 用 较 大 的 块 ， 比 较 好 
的 解决 方式 是 取 一 个 折 中 的 值 〈 或 者 将 这 两 个 集 
合 放 在 不 同 的 集群 中 ) 。 


如 果 MongoDB 频 繁 进行 数据 迁移 或 文档 较 大 ， 则 
可 能 需要 增加 块 的 大 小 。 










































































16.4.3 ”移动 块 











如 前 所 述 ， 同 一 块 内 的 所 有 数据 都 位 于 同一 分 片 
上 。 如 该 分 片 的 块 数量 比 其 他 分 片 多 ， 则 
MongoDB 会 将 其 中 的 一 部 分 块 移 至 其 他 块 数 量 较 
少 的 分 片上 。 移 动 块 的 过 程 叫做 迁移 
(migration)〉，MongoDB 就 是 这 样 在 集群 中 实现 
数据 均衡 的 。 


可 在 shell 中 使 用 moveChunk 辅 助 函数 ， 手 动 移动 
H: 


T 

























































































> sh.moveChunk("test.users", {"user_id" 
"spock") 
{ "millis" : 4079, "ok" : 1 } 





以 上 命令 会 将 包含 文档 user_id 为 
1844674407370955160 的 块 移 至 名 为 spock 的 分 片 














。 必 须 使 用 片 键 来 找 出 所 需 移动 的 块 〈 本 例 
Eusen. id) 。 通 常 ， 指 定 一 个 块 最 简 
的 方式 是 指定 它 的 下 边界 ， 不 过 指定 块 范 丽 
任何 值 都 可 以 〈 块 的 上 边界 值 除 外 ， 因 为 其 并 
包含 在 块 范围 内 ) 。 该 命令 在 块 移 动 完 成 后 才 
返回 ， 因 此 需 一 定 耗 时 才能 看 到 输出 信息 。 女 
个 操作 耗 时 较 长 ， 可 在 日 志 中 详细 查看 问题 所 
在 。 


如 某 个 块 的 大 小 超出 了 系统 指定 的 最 大 值 ， 
mongos 则 会 拒绝 移动 这 个 块 : 
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> sh.moveChunk("test.users", {"user_id" 
"spock") 
{ 


"cause" : { 
"chunkTooBig" : true, 
"estimatedChunkSize" : 2214960, 
"ok" : 0, 
"errmsg" : “chunk too big to move" 
J 
"ok" : @, 
"errmsg" : "move failed" 





} 








本 例 中 ， 移 动 这 个 块 之 前 ， 必 须 先 手动 拆 分 这 个 
块 。 可 使 用 splitAt 命 令 对 块 进行 拆 分 : 
































> db.chunks.find({"ns" : "test.users", 
... "min.user_id" : NumberLong("1844674407 
{ 


"_id" : "test.users-user_id NumberLong 
"ns" : "test.users", 
" : { "user_id" : NumberLong("1844 
"max" : { "user_id" : NumberLong("2103 
"shard" : "test-rs2" 


> sh.splitAt("test.ips", {"user_id" : Numb 
{ "ok" : 1 } 

> db.chunks.find({"ns" : "test.users", 
"min.user_id" : {"$gt" : NumberLong("1 
"max.user_id" : {"$1t" : NumberLong("2 


{ 
"_id" : "test.users-user_id NumberLong 
"ns" "test.users", 
"min" : { "user_id" : NumberLong("1844 
"max" : { "user_id" : NumberLong("2000 
"shard" : "test-rs2" 

} 

{ 
"_id" : "test.users-user id NumberLong 
"ns" : "test.users", 
"min" { "user_id" : NumberLong("2666 


"max" : { "user_id" : NumberLong("2103 
"shard" : "test-rs2" 








块 被 拆 分 为 较 小 的 块 后 ， 就 可 以 被 移动 了 。 也 可 
以 调 高 最 大 块 的 大 小 ， 然 后 再 移动 这 个 较 大 的 
块 。 不 过 应 尽 可 能 地 将 大 块 拆 分 为 小 块 。 不 过 有 
时 有 些 块 无 法 被 拆 分 ， 这 些 块 被 称 作 特大 块 。 














16.4.4 ”特大 块 














假设 使 用 date 字 段 作为 片 键 。 集 合 中 的 date 字 
段 是 一 个 日 期 字符 串 ， 格 式 

为 year/month/day， 也 就 是 说 ，mongos 一 天 最 
多 只 能 创建 一 个 块 。 最 初 的 一 段 时 间 内 一 切 正 
常 ， 直 到 有 一 天 ， 应 用 程序 的 业务 量 突然 出 现 病 
毒 式 增长 ， 流 量 比 平常 大 了 上 千 倍 ! 


这 一 天 的 块 要 比 其 他 日 期 的 大 得 多 ， 但 由 于 块 内 
所 有 文档 的 片 键 值 都 是 一 样 的 ， 因 此 这 个 块 是 不 
可 拆 分 的 


如 果 块 的 大 小 超出 了 config.settings 中 设置 的 最 大 
块 大 小 ， 那 么 均衡 器 就 无 法 移动 这 个 块 了 。 这 种 
不 可 拆 分 和 移动 的 块 就 叫做 特大 块 ， 这 种 块 相当 
难 对 付 。 


举例 来 说 ， 假 如 有 3 个 分 片 shard1、shard2 和 和 
shard3。 如 果 使 用 热点 片 键 模式 (参见 15.2.1 
) ， 假 设 shard1 是 热点 片 键 ， 则 所 有 写 请 求 都 



















































































































































































会 被 分 发 到 shard1 上 。mongos 会 试图 将 块 均衡 地 
分 发 在 这 些 分 片上 。 但 是 ， 均 衡器 只 能 移动 非特 
大 块 ， 因 此 它 只 会 将 所 有 较 小 块 从 热点 分 片 迁移 
到 其 他 分 片 。 


现在 ， 所 有 分 片上 的 块 数 基本 相同 ， 但 shard2 和 
shard3 上 的 所 有 块 都 小 于 64 MB。 如 shard1 上 出 现 
了 特大 块 ， 则 shard1 上 会 有 越 来 越 多 的 块 大 于 64 
MB。 这 样 ， 即 使 三 个 分 片 的 块 数 非常 均衡 ， 

但 shard1 会 比 另 两 个 分 片 更 早 被 填 满 。 


出 现 特大 块 的 表现 之 一 是 ， 某 分 片 的 大 小 增长 速 
度 要 比 其 他 分 片 快 得 多 。 也 可 使 用 
sh.status O 来 检查 是 否 出 现 了 特大 块 : 特大 
块 会 存在 一 个 jumbo 属 性 。 

































































































































































> sh.status() 


x" : -7 } -->> { "x" :5}on: sha 
x" : 5 } -->> { "x" : 6 } on : shar 
"x" : 6 } -->> { "x" : 7 } on : shar 
x" : 7 } -->> { "x" : 339 } on : sh 





AAAS 














可 使 用 datasize 命 令 检查 块 大 小 。 
和 先 ， 使 用 config.chunks 集 合 ， 查 看 块 范围 : 
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> Use config 
> var chunks = db.chunks.find({"ns" : "acm 





然后 根据 这 些 块 范围 ， 找 出 可 能 的 特大 块 : 














> use dbName 





> db.runCommand({"dataSize" : "dbName.collName", 
"keyPattern" : {"date" : 1}, // 片 键 
. "min" : chunks[0].min, 
. "max" : chunks [0].max}) 





{ "size" : 11270888, "numObjects" : 128081, "millis" 











但 要 小 心 ， 因 为 dataSsize 命 令 要 扫描 整个 块 的 
数据 才能 知道 块 的 大 小 。 因 此 如 果 可 能 ， 应 首先 
根据 自己 对 数据 的 了 解 ， 尽 可 能 缩小 搜索 范围 : 
特大 块 是 在 特定 日 期 出 现 的 吗 ? 例如 ， 如 果 11 月 
1 号 的 时 候 系 统 非常 繁忙 ， 则 可 尝试 检查 这 一 天 
创建 的 块 的 片 键 范围 。 如 使 用 了 GridFS， 而 且 是 
依据 files_id 字 段 进 行 分 片 的 ， 则 可 通过 fs.files 
集合 查看 文件 大 小 。 


1. 分 发 特大 块 


ed 须 将 特 
大 块 均衡 地 分 发 到 其 他 分 片上 


这 是 一 个 非常 复杂 的 手动 过 程 ， 而 且 不 应 引起 停 
机 《可 能 会 导致 系统 变 慢 ， 因 为 要 迁移 大 量 的 数 





































































































































































































据 ) 。 接 下 来 ， 我 们 以 from 分 片 来 指 代 拥 有 特大 
块 的 分 片 ， 以 to 分 片 来 指 代 特 大 块 即 将 移 至 的 目 

标 分 片 。 注 意 ， 如 有 多 个 fom 分 片 ， 则 需 对 每 个 
from 分 片 重 复 下 列 步 又 : 


1. 关闭 均衡 器 ， 以 防 其 在 这 一 过 程 中 出 来 的 
乱 : 


> sh.setBalancerState(false) 


2. MongoDB 不 允许 移动 大 小 超出 最 大 块 大 小 设 
定 值 的 块 ， 所 以 需 临 时 调 高 最 大 块 大 小 的 设 
定 值 。 记 下 特大 块 的 大 小 ， 然 后 将 最 大 块 大 
小 设 定 值 调整 为 比特 大 块 大 一 些 的 数值 ， 比 
如 10 000。 块 大 小 的 单位 是 MB: 



























































> use config 
> db.settings.findOne({"_id" : "chunks 
{ 
"Vid" : "chunksize", 
"value" : 64 
> db.settings.save({"_id" : "chunksize 

















3. 使 用 moveChunk 命 令 将 特大 块 从 from 分 片 移 
至 to 分 片 。 如 担心 迁移 会 对 应 用 程序 的 性 能 
造成 影响 ， 可 使 用 secondaryThroot1le 选 




































































项 ， 放 慢 迁 移 的 过 程 ， 减 缓 对 系统 性 能 的 影 

响 : 

> db.adminCommand({"moveChunk" : "acme 
"find" : {"date" : new Date("10/23 
"to" : "shardeee2", 


"secondaryThrottle" : true}) 











secondaryThrottle 会 强制 要 求 迁移 过 程 间 
其 进行 ， 每 迁移 完 一 些 数据 ， 需 等 待 集群 中 
的 大 多 数 分 片 成 功 完成 数据 复制 后 再 进行 下 
一 次 迁移 。 该 选项 只 有 在 使 用 副本 集 分 片 时 
才 会 生效 。 如 使 用 单机 服务 器 分 片 ， 则 该 选 
项 不 会 生效 。 


4. 使 用 splitChunk 命 令 对 from 分 片 剩 余 的 块 进 
行 拆 分 ， 这 样 可 以 增加 from 分 片 的 块 数 ， 直 
到 实现 fom 分 片 与 其 他 分 片 块 数 的 均衡 。 





















































































































































5. 将 块 大 小 修改 回 最 初 值 ; 
> db.settings.save({"_id" : "chunksize 


























6. 启用 均衡 器 。 


> sh.setBalancerState(true) 


























均衡 器 被 











再 次 启 月 
过 此 时 那些 特大 二 














2. 防止 出 现 特大 块 





有 上 后， 仍旧 不 能 移动 特大 块 ， 不 
都 已 位 于 合适 的 位 置 了 。 





随 着 存储 数据 
es 
， 应 


























1 先 想 办 法 


为 防止 特大 块 的 出 现 ， 可 
粒度 。 应 尽 可 能 保证 每 个 文档 都 扩 
值 ， 或 至 少 不 要 H 
大 块 大 小 设 定 值 的 | 





量 的 增长 ， 上 


节 提 到 的 手动 过 程 








因此 ， 如 在 特大 块 方面 存在 问 








避免 特大 块 的 出 现 。 
修改 片 键 ， 细 化 片 键 的 





























EE 





青 况 。 

















列 如 ， 如 使 用 


























的 第 一 





SIME. AP. POR 
粒度 较 大 的 片 键 ， 
粒度 较 细 的 字段 
散 列 值 或 UDID。 
个 字段 值 是 相同 的 ， 
分 ， 也 就 防止 了 特大 块 的 出 现 。 


前 面 所 述 的 年 /月 
| 化 片 键 粒度 。 
如 日 志 级 别 ， 



































现 某 个 片 键 值 的 数据 块 超 





/日 


有 有 唯一 的 片 键 
出 最 











片 键 ， 可 通过 
类 似 地 ， 如 使 
则 可 添加 一 个 


年 为 片 键 的 第 二 个 字段 ， 如 MD5 








这 样 一 来 ， 





也 可 


即使 有 许多 文档 片 键 























直 对 块 进行 拆 























16.4.5 刷新 配置 


E, 



































最 后 一 点 ，mongos 有 时 无 法 从 配置 服务 器 正确 更 



































新 配置 。 如 发 现 配 置 有 误 ，mongos 的 配置 过 旧 或 
无 法 找到 应 有 数据 ， 可 使 用 flushRouterConfig 
命令 手动 刷新 所 有 缓存 : 


>db.adminCommand({"flushRouterConfig" : 1} 











































































































如 flushRouterConfig 命 令 没 能 解决 问题 ， 则 应 
= 局 所 有 的 mongos Naas 以 便 清除 所 有 
能 的 缓存 。 


























第 五 音 ZN 
部 分 应 用 管理 


第 17 章 了解 应 用 的 动态 


启动 并 运行 应 用 后 ， 要 如 何 知道 它 正 在 做 些 什么 
We? 本 章 将 介绍 如 何 了 解 MongoDB 正 在 进行 何 种 
查询 ， 有 多 少数 据 正在 写 入 ， 以 及 如 何 探查 
MongoDB 具 体 正 在 做 些 什么 。 我 们 将 学 到 : 


。 如 何 找到 并 终止 那些 拖 慢 速度 的 操作 ; 
。 获取 并 分 析 有 关 集 合 和 数据 库 的 统计 数据 ; 
e | 

么 












































































































































命令 行 工具 来 了 解 MongoDB 正 在 做 些 什 








17.1 了 解 正 在 进行 的 操作 


要 想 找到 是 哪些 操作 拖 慢 了 速度 ， 看 看 正在 进行 

澡 作 不 失 为 一 种 简单 的 方法 。 速 度 慢 的 操作 耗 
时 更 长 ， 更 有 可 能 被 发 现 。 虽 然 不 能 保证 一 定 会 
有 结果 ， 但 这 是 个 不 错 的 开始 。 
































































































































看 正在 进行 的 操作 ， 可 使 用 db .currentoOp() 





> db.currentOp() 


{ 
"inprog" : [ 
{ 





"opid" : 34820, 
"active" : true, 
"secs running" : 0, 
"op" "query", 
"ns" "test.users", 
"query" : { 
"count" : "users", 
"query" : { 
"username" > 
}s 
"fields" : { 
} 
J 
"client" : "127.0.0.1:39931", 
"desc" "conn3", 
"threadId" : "@x7f12d61c770e", 
"connectionId" : 3, 
"locks" : { 
TAE ee Ig 
“Atest™ q- TRY 
hs 
"waitingForLock" : false, 
"numYields" : @, 
"lockStats" : { 
"timeLockedMicros" { 
}s 


"timeAcquiringMicros" 





}, 




















"rp" : NumberLo 
"w" : NumberLo 


=~ 


该 函数 会 列 出 数据 库 正 在 进行 的 所 有 操作 ， 输 出 














的 信息 中 有 些 重 要 的 字段 。 


@ opid 





这 是 操作 的 唯一 标识 符 Gdentifier) ， 可 通 
过 它 来 终止 一 个 操作 (参见 17.1.2 节 )。 


e active 





表示 该 操作 是 否 正在 运行 。 如 这 一 字段 的 值 


是 false， 意 味 着 此 操作 已 交 出 或 正 等 待 其 





他 操作 交 出 锁 。 


e secs _running 











表示 该 操作 已 经 执行 的 时 间 。 








断 是 哪些 查询 耗 时 过 长 ， 或 者 占用 了 过 多 的 


数据 库 资源 。 


e Op 























新 、 删 除 中 的 一 种 。 注 意 ， 








表示 操作 的 类 型 。 通 常 是 查询 、 插 入 、 
oe 


可 通过 它 来 判 

















作为 查询 操作 来 处 理 。 





e desc 


该 值 可 与 








志 (log) 信息 联系 起 来 。 





志 中 





与 此 连接 相关 的 每 一 条 记录 都 会 以 [conn3] 








为 前 级 ， 因 


locks 


























描述 该 操作 使 用 
局 锁 。 
e waitingForLoc 
表示 该 操作 是 否 





此 可 以 此 来 筛选 相关 的 


日 志 信 

















的 锁 的 类 型 。 


k 
K| | 


























而 处 于 阻塞 状态 。 


numYields 
表示 i 
得 以 运行 的 次 数 。 
WE CEW 
其 他 操 


ZN É 





H 





A 

















己 的 锁 。 








新 和 删除 ) 可 
攻 列 队 等 待 该 操作 所 持 的 锁 


如 果 没 有 


E 在 等 待 





玄 操 作 交 出 锁 〈yield) ， 而 使 其 


其 他 操作 交 出 


其 中 心 表 示 全 








锁 


其 他 操作 


通常 ， 进 行文 档 搜索 的 操 





简单 地 讲 ， 


J 交 出 锁 。 


| 


会 交 出 锁 。 


锁 。 


在 执行 currentOp() 时 ， 可 添加 过 滤 
的 结果 。 例 如 ， 

















只 显示 符合 条 件 





(m 





有 在 
它 才 
其 他 
， 则 该 操作 












































O Er 


表示 该 操作 需要 多 长 时 间 才 能 取得 


所 需 的 





条 件 





， 从 而 





八 显示 在 某 一 

















名 空 间 中 进行 的 操作 ， 或 上 只 显示 已 运行 了 定时 
间 的 操作 。 把 查询 条 件 作 为 参数 传 入 函数 来 进行 
Wye: 











> db.currentOp({"ns" : "prod.users"}) 

















对 于 currentop 中 的 任何 字段 都 可 以 进行 查询 ， 
使 用 普通 的 查询 语句 即 可 。 












































17.1.1 寻找 有 问题 的 操作 




















db.currentop() 最 常见 的 作用 就 是 用 来 寻找 速 
度 较 慢 的 操作 。 可 采用 上 一 节 中 提 到 的 过 滤 方 

法 ， 来 查找 哪些 查询 消耗 的 时 间 超 过 了 一 定 的 

值 。 也 许 能 通过 该 方法 找 出 哪里 缺少 了 索引 ， 或 
i 当 的 条 件 过 滤 。 


有 时 会 发 现 正在 运行 一 些 不 明 查 询 ， 这 通常 是 
于 一 个 应 用 服务 器 在 运行 一 个 旧 的 或 有 漏洞 的 软 
件 版 本 所 导致 的 。"client" 字 有 段 可 用 来 帮 
踪 找 出 这 些 不 明 操 作 的 来 源 。 



































































































































dA 
= 
(it 





17.1.2 终止 操作 的 执行 














只 要 找到 了 想 要 终止 的 操作 ， 就 可 将 该 操作 的 














opid 作 为 参数 ， 通 过 执行 db .kill0p( ) 来 终止 该 








操作 的 执行 : 








> db.killOp(123) 














并 非 所 有 操作 都 能 被 终止 。 











ERY KAZH 























了 锁 的 进程 才能 被 终止 
查找 (find) 
JE 正在 占 上 






























































如 果 问 

















对 此 更 新 Cupdate) ~ 





、 删 除 (remove) 操作 都 可 被 终 
j 锁 ， 或 正在 等 待 其 他 操作 交 出 锁 的 
操作 则 通常 无 法 被 终止 。 


个 操作 发 出 了 “kill* 信 号 ， 那 么 它 











在 db.currentOp 的 输出 中 就 会 有 一 个 killed 字 
段 。 然 而 ， 只 有 从 当前 操作 列表 消失 后 ， 它 才 会 








上 
H 





























E 的 得 到 终止。 


17.1.3 ”假象 

















在 查找 哪些 操作 耗 时 过 长 时 ， 可 能 会 发 现 一 些 长 





时 间 运 行 的 内 部 操作 。 届 
会 长 时 间 地 执行 若干 请 求 。 
(replication) 的 线程 ( 





民 据 设置 ，MongoDB 可 能 














最 常见 的 是 用 于 复制 











它 会 持续 向 同步 源 请 求 更 











多 的 操作 ) 和 分 片 中 用 了 


可 写 Cwriteback) 的 监 











WZ% (listener) 。 所 有 1o 














cal.oplog.rs 中 的 长 

















时 间 运 行 i 
被 忽略 掉 。 




















求 ， 以 及 所 有 





习 写 监听 命令 ， 都 可 以 





如 以 上 操作 被 终止 ，MongoDB 则 会 重启 它们 。 不 














过 ， 通 常 我 们 不 应 该 这 么 做 。 终 
旦 会 短暂 地 中 止 复制 操作 ， 而 终 
则 可 能 会 造成 mongos 遗 漏 J 








>H 























止 用 于 复制 的 线 














17.1.4 避免 幽灵 操作 














上 掉 回 写 监 听 器 














正常 的 写 入 错误 。 











这 是 一 个 不 常见 的 ， 只 有 在 MongoDB 中 才 可 能 会 

















遇 到 的 问题 ， 尤 其 是 在 进行 静态 加 载 (bulk- 








loading) 数据 至 集合 的 时 候 。 假 设 现在 我 们 建立 
了 一 个 任务 Gob) ， 用 于 在 MongoDB 中 进行 上 
于 条 更 新 操作 ， 而 MongoDB 正 逐 

















们 迅速 停止 了 这 一 








任务 ， 终止 








渐 趋 于 停止 。 我 








了 正在 进行 的 所 有 








更 新 操作 。 然 而 ， E i 




















出 现 ， ASAE 任务 已 经 


























不 再 运行 ! 
































如 果 使 用 非 应 答 式 写 入 〈unacknowledge write) 











加 载 数据 ， 应 用 





= 











发 写 入 操作 的 速度 可 能 要 比 


MongoDB 处 理 的 速度 更 快 。 如 MongoDB 有 所 准 











备 ， 这 些 写 入 会 














(socket buffer) ! 














写 入 操作 后 ，MongoDB 则 开始 








E 积 在 操作 系统 的 套 接 字 缓存 














。 终 止 掉 MongoDB 正 在 进行 的 











处 天 


缓存 区 中 的 写 








入 操作 。 即 使 停止 客户 端 发 送 ，MongoDB 也 会 处 




















理 这 些 缓存 中 的 写 入 请 求 ， 基 











为 它 


们 已 经 被 
































MongoDB 所 接收 了 ， 只 不 过 还 没有 进行 处 理 而 











Go 


阻止 这 些 幽 灵 写 入 的 最 好 方式 是 使 用 应 答 式 写 
入 ， 即 每 次 写 入 操作 都 会 等 待 上 一 次 写 入 操作 完 
成 后 才 会 进行 下 去 ， 而 非 在 上 一 次 写 入 进入 数据 
库 服务 器 的 缓存 区 就 开始 下 一 次 写 入 。 


17.2 ”使 用 系统 分 析 器 


可 利用 系统 分 析 器 (system profiler) 来 查找 耗 时 
过 长 的 操作 。 系 统 分 析 器 可 记录 特殊 集合 
systemprofile 中 的 操作 ， 并 提供 大 量 有 关 耗 时 过 
长 的 操作 信息 ， 但 相应 的 ，mongod 的 整体 性 能 也 
会 有 所 下 降 。 因 此 ， 我 们 可 能 只 需 定期 打开 分 析 
器 来 获取 信息 即 可 。 则 建 
议 使 用 本 章 介 绍 的 另 一 方法 来 解决 问题 


默认 情况 下 ， 系 统 分 析 器 处 于 关闭 状态 ， 不 会 进 
行 任何 记录 。 可 在 shell 中 运行 
db.setProfilingLevel()F¥ Ja 41 #8: 
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> db.setProfilingLevel(2) 
{ "was" : ©, "slowms" : 100, "ok" : 1 } 











以 上 命令 将 分 析 器 的 级 别 设 定 为 2 级 ， 意 味 着 "分 
析 器 会 记录 所 有 内 容 "。 数 据 库 收 到 的 所 有 读 写 











请 求 都 将 被 记录 在 当前 数据 库 的 
system.profile 集 合 中 。 每 一 个 数据 库 都 启用 
了 分 析 器 ， 这 也 将 带 来 大 量 的 性 能 损失 ， 因 为 每 
一 次 写 操作 都 会 增加 额外 的 写 入 时 间 ， 而 每 一 次 
读 操 作 都 要 等 待 写 锁 (因为 它 必须 在 
system.profile 集 合 中 写 入 记录 ) 。 然 而 ， 它 也 会 
提供 给 我 们 系统 进行 操作 的 详尽 列表 : 










































































db.foo.insert({x:1}) 
db.foo.update({}, {$set:{x:2}}) 
db.foo.remove() 
db.system.profile.find().pretty() 


mV vvyY 


"ts" : ISODate("2012-11-07T18: 32:3 
"op" : "insert", 

"ns" : "test.foo", 

"millis" : 37, 

"client" : "127.0.0.1", 

"user" : "" 


一 


"ts" : ISODate("2012-11-07T18: 32:4 
"op" : "update", 

"ns" : "test.foo", 

"query" : { 


J 
"updateobj" : { 














XD 
} 
}s 
"nscanned" : 1, 
"fastmod" : true, 
"millis" : 3, 
"client" : "127.0.0.1", 
"user" z "" 
} 
{ 
"ts" : ISODate("2012-11-07T18:3 
"op" : "remove", 
"ns" : "test.foo", 
"query" : { 
3 
"millis" : 6， 
"client" : "127.0.0.1", 
"user" : "" 
} 








在 "client”( 客 户 端 ) 字段 中 可 看 到 各 操作 是 
由 哪个 用 户 发 送 至 数据 库 的 。 如 果 启 用 了 身份 验 
证 系统 ， 也 能 够 看 到 各 操作 是 由 哪些 用 户 运行 
的 。 






















































































一 般 情 况 下 ， 我们 只 想 关 注 那 些 耗 时 过 长 的 操 
作 ， 而 非 数据 库 中 正在 进行 的 所 有 操作 。 为 此 ， 





























可 将 分 析 器 的 分 析 级 别 设 为 1， 即 只 显示 长 耗 时 
操作 。 级 别 为 1 的 分 析 器 会 默认 记录 耗 时 大 于 100 
ms 的 操作 。 也 可 以 自 定义 “ 耗 时 过 长 ”的 标准 ， 把 
这 个 值 作 为 db.setProfillingLevel() 函 数 的 
第 二 个 参数 。 以 下 命令 会 记录 所 有 耗 时 超过 500 
ms 的 操作 : 


> db.setProfilingLevel(1, 500) 
{ "was" : 2, "slowms" : 100, "ok" : 1 } 






































将 分 析 级 别 设 为 0 可 关闭 分 析 器 。 


> db.setProfilingLevel(@) 
{ "was" : 1, "slowms" : 500, "ok" : 1 } 























通常 情况 下 ， 不 要 将 slowms 的 值 设 得 过 小 。 即 使 
分 析 器 处 于 关闭 状态 >，Slowms 也 会 对 mongod 有 

所 影响 ， 因 为 它 决 定 了 哪些 操作 将 作为 耗 时 过 长 
操作 被 记录 到 日 志 中 。 因 此 ， 如 果 将 slowms 设 为 
2 ms， 那 么 哪怕 分 析 器 是 关闭 着 的 ， 每 个 耗 时 超 
过 2 ms 的 操作 也 都 会 出 现在 日 志 里 。 因 此 ， 如 果 
出 于 某 些 需求 降低 了 slowms 的 值 ， 那 么 应 在 关闭 
分 析 器 前 将 它 重 新 调 高 。 


可 通过 db.getProfilingLevel() 来 查看 当前 的 
分 析 级 别 。 分 析 级 别 的 设 定 值 会 在 重启 数据 库 后 


































































































被 清除 。 











也 可 在 


命令 行 


Pp 使) 





HH 


J--profile level fll-- 


slowms time 选 项 来 配置 分 析 器 的 级 别 。 但 更 改 











分 析 级 别 通常 只 是 在 jj 








而 不 应 该 将 其 长 期 4 


如 开启 了 分 析 器 而 system.profile 集 合并 不 存在 ， 





周斌 
加 入 配 














Ne 





aA 
中 。 





临时 措施 ， 
































MongoDB 会 为 
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建立 一 个 大 小 为 若 了 
集合 (capped collection) > WERN 











长 时 间 ， 可 
作 。 此 时 可 关闭 分 





的 名 为 system.profile 的 


合 需 求 。 然 后 在 数 提 





17.3 
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会 已 


能 得 





计算 空间 消耗 
RISC. Bl. 


fe BE KIN 


Far Mtl 

















固定 

器 运行 更 
辣 来 记录 更 多 的 操 
除 并 重新 建立 一 个 


FMB 的 












































固定 集合 ， 





新 
并 令 其 








EEEE 








集合 

















少 空间 ， 就 可 以 方便 


地 预 留 


























空间 。 关 于 计算 了 


21 章 。 





17.3.1 文档 








TE 
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查询 文档 占 









































令 其 容量 符 
分 析 器 。 





J) 





、 数 据 库 各 占用 了 多 
出 合适 的 磁盘 和 内 存 














[ 作 集 大 小 的 相关 内 容 请 参见 第 








的 空间 大 小 ， 最 简 刷 











的 方法 是 在 




















shell 中 对 文档 使 用 Object.bsonsize() 函 数 。 此 
函数 将 返回 该 文档 存储 在 MongoDB 中 时 占用 的 空 
间 大 小 。 


例如 ， 我 们 可 以 看 到 ， 将 _id 存 储 为 0bjectId 类 
型 ， 比 存储 为 字符 串 类 型 效率 更 高 。 


> Object. bsonsize({_id:ObjectId()}) 

22 

> // ""+0bjectId() 将 ObjectId 转换 为 字符 串 
> Object.bsonsize({_id:""+0bjectId()}) 

39 




























































































也 可 以 直接 对 集合 中 的 文档 进行 查询 : 


> 0bject.bsonsize(db.users.findone()) 


















































一 函数 会 精确 地 告知 文档 在 磁盘 上 占用 的 字 节 
数目 。 然 而 这 其 中 并 未 包括 自动 生成 的 空间 间隔 
(padding) 和 索引 ， 二 者 也 时 常 是 影响 集合 大 小 
的 重要 因素 。 










































































17.3.2 集合 




















stats 函 数 可 用 来 显示 一 个 集合 的 信 


[> db.boards.stats() 


cal 





























{ 
"ns" : "brains.boards", 
"count" : 12, 
"size" : 32292, 
"avgObjSize" : 2691, 
"storageSize" : 270336, 
"numExtents" : 3, 
"nindexes" : 2, 
"lastExtentSize" : 212992, 
"paddingFactor" : 1.009999999999982 
"flags" : 1, 
"“totalIndexSize" : 16352, 
"indexSizes" : { 
" id " : 8176, 
"username 1 slug 1" : 8176 
}, 
"ok" : 1 
} 
stats 函 数 的 返回 结果 中 首先 是 命名 空间 














( 即 brains .boards) ， 接 下 来 是 集合 中 文档 的 

















数目 。 再 接 下 来 的 几 个 字段 与 集合 的 大 小 有 








关 。size 的 值 相 当 于 对 此 集合 





4{yObject.bsonsize(), 
的 值 ， 即 集合 中 所 有 文档 











口 






































再 将 i 
5 有 的 字 











节 数 。 

















将 avg0bjSize 平均 对 象 大 小 ) ‘Ficounts 





也 能 得 到 size 的 值 。 











FP 的 所 有 元 素 执 
这 些 结 果 相 力 


[得 到 





HF, 










































































































































































与 之 前 提 到 的 一 样 ， 所 有 文档 占用 的 字 节 总 数 并 
不 等 于 集合 大 小 ， 集 合 还 占用 空间 存放 其 他 重要 
内 容 ， 即 文档 间 的 间隔 和 索引 信息 。 

而 storageSize 不 仅 仅 包含 这 些 内 容 ， 还 包含 集合 
两 端 预 留 的 未 经 使 用 空间 。 集 合 末 端 总 有 些 空余 
空间 ， 以 便 新 文档 能 够 快速 添加 进来 。 
nindexes 是 集合 中 索引 的 数量 。 索 引 直 到 建立 
完成 后 才 会 被 算 在 nindexes 中 ， 也 只 有 在 出 现 
在 此 列表 后 才 可 以 被 使 用 。 由 于 目前 的 集合 还 很 








小 ， 所 以 每 个 索引 都 只 有 一 个 






































小 (8 RBS 

















桶 ”(bucket) 大 
通常 来 讲 ， 索 引 比 存储 的 数据 量 大 























很 多 ， 含 有 很 多 空闲 空间 ， 以 便 在 增 








aay 时 进行 


balanced index， 

















优化 。 使 用 右 平衡 索 





加 新 入 口 
J ,righ 


















































参见 5.1.1 节 ) 可 将 这 
减 至 最 小 。 而 随机 分 布 的 索引 通常 会 有 50% 左 右 
的 空闲 空 oe 升序 索引 Cascending-order index) 

则 有 10% 的 空闲 空间 。 








一 空 采 空间 







































































随 着 集合 的 不 断 增长 ， stats() 返 回 的 巨大 字 节 
数目 可 能 会 变 得 不 易 辩 识 。 因 此 ， 可 在 使 
stats 时 传 入 比例 因子 (scale factor) : KB 值 
为 1024，MB 则 为 1024x1024， 依 次 类 推 。 例 如 ， 
以 下 命令 会 以 TB 为 单位 显示 集合 信息 : 











> db. big. stats(1024*1024*1024*1024) 











17.3.3 数据库 








数据 库 的 stats 函 数 与 集合 的 类 似 : 











> db.stats() 

{ 
"db" : "brains", 
"collections" : 11, 
"objects" : 1109, 
"avgObjSize" : 299.79440937781783 
"dataSize" : 332472, 
"storageSize" : 1654784, 
"numExtents" : 15, 
"indexes" : 11, 
"“indexSize" : 114464, 
"fileSize" : 201326592, 
"nsSizeMB" : 16, 
"ok" : 1 

} 
































和 先 返 回 的 是 数据 库 名 称 和 其 中 包含 的 集合 数 
目 。objects 的 值 是 数据 库 中 所 有 集合 包含 的 文 
档 总 数 。 

输出 中 包含 了 有 关 数 据 大 小 的 信息 。filesSize 


应 该 总 是 最 大 的 ， 即 为 数据 库 文件 分 配 的 总 空 
间 。 该 值 应 等 于 数据 目录 中 所 有 名 为 brains.* 的 文 

































































件 大 小 总 和 。 
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在 使 用 
件 。 例 


brains.1 和 brains. 





的 总 空 


























大 小 。 


如 ， 如 果 数 
2 文人 
brains.2 写 入 数据 后 ， 文 件 





第 二 大 的 字段 通常 是 storageSize， 即 数据 库 正 
该 值 与 filesize 不 符 ， 
E a > 配 Cpreallocated) X 




















E Hx F OAT Ebrains.0 
FEF， 则 brains.2 会 被 0 填 满 。 
F brains.3 会 被 预 分 











AIC « 








每 个 数据 库 内 应 





EFA 











件 














间 的 差异 。 


dataSize 是 此 数据 库 中 的 数 志 


该 空 文件 被 写 入 数据 
预 分 配 。 因 此 ， 该 空 文件 (以 及 前 盏 
使 用 的 部 分 ) 造成 了 fileSsize 和 storageSize 














个 填充 为 0 的 空 
后 ’ 下 一 个 文件 


oe 
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居所 占用 的 空 





| 文件 : 
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> ER, BAH 


F 不 包含 空 


闲 列表 
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的 空间 ， 但 





/小 。 é 

















包含 








文档 间 的 间 
直 的 差异 ， 应 为 被 删 





与 storageSizef 











与 集合 的 stats() 一 相 
EAB 























如 果 对 


个 不 存 1 
则 nsSsizeMB 的 值 为 0。 





在 的 数据 / 





隔 。 





特使 月 


Hd 


寻 此 该 值 



































b.stats()， 


这 是 .ns 文件 的 大 小 ， 它 本 








质 上 相当 








于 数据 库 中 的 内 容 表 。 





4 





F 何 存在 的 数 


未 被 


free list) 中 


除 文 档 的 大 


E，db.stats() 可 接收 一 个 





=i 


ii 








类 操作 。 


库 均 需 一 个 .ns 文件 。 


记 住 ， 在 一 个 繁忙 的 系统 上 列 出 数据 库 信息 会 非 
常 慢 ， 而 且 会 阻碍 其 他 操作 。 因 此 应 尽量 避免 此 























17.4 ”使 用 mongotop 和 monogostat 














MongoDB 自 带 了 几 个 命令 行 工 具 ， 可 通过 每 隔 几 
秒 输出 当前 状态 ， 帮 助 我 们 判断 数据 库 正在 做 些 


什么 。 



































mongotop 类 似 于 UNIX 中 的 top 工 具 ， 可 概述 哪个 




















集合 最 为 繁忙 。 可 通过 运行 Wongotop-locks， 


从 而 得 知 每 个 数据 库 的 锁 状 态 。 


mongostat 提 供 有 关 月 
每 秒 输 出 一 次 



































及 务 器 的 信息 。mongostat 默 认 
包含 当前 状态 的 列表 ， 可 在 命令 行 
中 传 入 参数 更 改 时 间 间 隔 。 每 个 字段 都 会 给 出 自 
上 一 次 被 输出 以 来 ， 所 对 应 的 活动 发 生 次 数 。 


























e insert / query / update / delete 
/ getmore / command 


每 利 


e flu 








对 应 操作 的 发 4 


shes 


次数。 





mongod 将 数据 刷新 (flush) 到 磁盘 的 次 数 。 








mapped 
mongod 所 映射 的 内 存 数 量 ， 通 常 约 等 于 数据 


录 的 大 小 。 




















vsize 

mongod 正 在 使 用 的 虚拟 内 存 大 小 ， 通 常 为 数 
据 目 录 的 2 倍 大 小 (一 次 用 于 映射 的 文件 ， 
一 次 用 于 日 记 系 统 ) 。 






































res 
mongod 正 在 使 用 的 内 存 大 小 ， 通 常 该 值 应 尽 
量 接近 机 器 的 所 有 内 存 大 小 。 


locked db 
在 上 一 个 时 间 片 中 ， 锁 定时 间 最 长 的 数据 
库 。 该 百分比 是 根据 数据 库 被 锁定 的 时 间 和 
全 局 锁 的 锁定 时 间 来 计算 的 ， 这 意味 着 该 值 
可 能 超过 100%。 







































































idx miss % 

输出 中 最 令 人 困惑 的 字段 名 。 指 有 多 少 索引 
在 访问 中 发 生 了 缺 页 中 断 (page fault) ， 即 
索引 入 口 (或 被 搜索 的 索引 内 容 〉 不 在 内 存 
中 ， 使 得 mongod 必 须 到 磁盘 中 进行 读 取 。 























e qr|qw 
读 写 操作 的 队列 (queue 大 小 ， 即 有 多 少 读 
























































写 操作 被 阻塞 ， 等 待 进行 处 理 。 






































e ar|aw 
指 活动 客户 端的 数量 ， 即 正在 进行 读 写 操 作 
的 客户 端 。 

e netIn 
通过 网 络 传输 进来 的 字 节 数 ， 由 MongoDB 进 


























行 统计 《不 必 和 操 作 系 统 的 统计 相等 ) 。 


e netOut 
通过 网 络 传输 出 的 字 节 数 ， 由 MongoDB 进 行 
统计 。 






































e conn 


此 服务 器 打开 的 连接 数 ， 包 括 输入 和 输出 连 
接 。 














e time 


指 以 上 统计 信息 所 用 时 间 。 


可 在 副本 集 或 分 片 集群 上 运行 mongostat。 如 使 
] - -discover 选 项 ，mongostat 会 尝试 在 初始 连 


接 的 成 员 中 寻找 副本 集 或 分 片 集群 中 的 所 有 成 















































— 
































， 每 台 服 务 器 也 会 每 秒针 对 每 个 成 员 输 出 一 行 
乱 。 对 于 较 大 集群 而 言 ， 该 选项 会 使 数据 输出 
多 过 快 而 不 易于 管理 ， 但 于 较 小 集群 而 言 却 很 
实用 ， 也 可 使 用 一 些 工具 将 其 输出 的 信息 转换 为 
更 可 读 的 形式 。 


要 想 获得 数据 库 中 正在 进行 的 操作 快照 ， 
mongostat 是 很 好 的 选择 ， 但 如 果 要 对 数据 库 进 行 
长 期 的 监控 ， 类 似 MMS 的 工具 可 能 更 为 适合 〈 参 
见 第 21 章 ) 。 
































































































































第 18 章 ”数据 管理 


本 章 将 学 习 如 何 管理 集合 与 数据 库 。 通 常 来 讲 ， 
这 部 分 内 容 并 非 每 天 都 能 用 到 ， 但 对 于 应 用 性 能 
却 无 比重 要 ， 有 具体 包括 了 : 


。 配置 用 户 账户 和 身份 验证 ; 

。 在 正在 运行 的 系统 中 建立 索引 ; 

。 对 新 服务 器 进行 “ 预 热 "， 以 便 快 速 上 线 ; 
o 整理 数据 文件 中 的 碎片 ; 

。 手动 预 分 配 新 的 数据 文件 。 


18.1 配置 身份 验证 


作为 系统 管理 员 ， 首 要 任务 之 一 就 是 确保 系统 安 
全 。 确 保 MongoDB 安 全 的 最 好 办 法 ， 即 在 一 个 可 
信 环 境 中 运行 ， 确 保 只 有 可 信 的 机 器 能 够 连接 到 
服务 器 。 也 就 是 说 ， 即 使 是 在 以 任务 为 颗粒 的 粗 
粒度 〈coarse-grained) WIIF, MongoDB, 
文 持 针 对 单个 连接 进行 身份 验证 。 















































































































































































































Ch 
“可 登陆 MongoDB 企 业 版 








Chttp://bit.ly/15nFgl3) 查看 更 多 复杂 的 安全 特 
性 。 在 http://docs.mongodb.org/manual/security 中 
可 找到 最 新 的 认证 和 授权 信息 。 



































18.1.1 身份 验证 基本 原理 



































MongoDB 中 ， 每 个 数据 库 的 实例 都 可 拥有 任意 多 
个 用 户 。 安 全 检查 开启 后 ， 只 有 通过 身份 验证 的 
j 户 才能 够 进行 数据 的 读 写 操作 。 


admin (管理 员 ) 和 local (ASHE) 是 两 个 特殊 的 
数据 库 ， 它 们 当中 的 用 户 可 对 任何 数据 库 进 行 操 
作 。 这 两 个 数据 库 中 的 用 户 可 被 看 作 是 超级 用 
户 。 经 认证 后 ， 管 理 员 用 户 可 对 任何 数据 库 进行 
读 写 ， 同 时 能 狗 执 行 某 些 只 有 管理 员 才能 执行 的 
命令 ， 如 1istDatabases 和 shutdown。 


已 开启 安全 检查 的 数据 库 在 被 启动 前 ， 应 至 少 添 
加 一 个 管理 员 用 户 。 我 们 来 看 一 个 小 例子 ， 假 设 
在 没有 开启 安全 检查 的 前 提 下 ， 已 在 shell 中 连接 
到 了 服务 器 : 







































































































































































































































































> use admin 

switched to db admin 

> db.addUser("root", "abcd"); 
{ 


"user" : "root", 
"readOnly" : false, 


"pwd" : "1la@f1c3c3aa1d592f49@a2addc559 
} 


> use test 

switched to db test 

> db.addUser("test_user", "efgh"); 
{ 


"user" : "test user", 
"readOnly" : false, 
"pwd" : "6076b96fc3fe6002c810268702646 


> db.addUser("read_user", "ijkl", true); 


{ 


"user" : "read user", 
"readOnly" : true, 
"pwd" : "f497e180c9dc0655292Fee5893c16 








} 


























在 以 上 操作 中 ， 我 们 增加 了 一 名 管理 员 用 
户 root， 又 在 名 为 test 的 数据 库 中 增加 了 两 个 
] 户 。 其 中 名 为 read_user 的 用 户 只 有 读 权限 而 
没有 写 权 限 。 在 shell 中 用 addUser 创 建 用 户 时 ， 
将 第 三 个 参数 readOnly 设 置 为 true， 即 可 创建 一 
个 只 读 权限 用 户 。 运 行 adduser 时 ， 必 须 拥有 相 
应 数据 库 的 写 入 权限 。 这 个 例子 中 由 于 我 们 还 没 
有 启用 安全 检查 ， 因 此 可 在 任 一 数据 库 上 运 
























































































































































行 addUser。 


> 
zi Bt AP 
BY 





除 添加 新 用 户外 ，addUserf 
j 户 密码 或 只 读 权 限 状 态 。 只 和 
ae addUser 时 ， 将 用 户 名 和 新 密 fia EL 
限 设置 作为 参数 即 可 。 





La 
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现在 重启 服务 器 ， 这 次 在 命令 行 选项 中 加 上 - - 
auth 参 数 ， 以 启用 安全 检查 。 启 用 后 ， 在 shell 中 
重新 连接 并 尝试 以 下 操作 : 




















> use test 
switched to db test 
> db.test.find(); 


error: { "$err" : "unauthorized for db [te 
> db.auth("read_user", "ijkl"); 
1 


> db.test.find(); 
{ "_id" : ObjectId("4bb007f53e8424663ea684 


> db.test. insert({"x" : 2}); 
unauthorized 

> db.auth("test_user", "efgh"); 
1 


> db.test.insert({"x": 2}); 








db.test.find(); 

"_id" : ObjectId("4bb007F53e8424663ea684 
" "id" : ObjectId("4bb@088cbe17157d7b9cac 
show dbs 

ssert: assert failed : listDatabases faile 
"assertion" : "unauthorized for db [adm 


YY PP Vv 


" 
3 


"errmsg" : "db assertion failure", 
"ok" : 6 
} 
> use admin 
switched to db admin 
> db.auth("root", "abcd"); 
1 
> show dbs 
admin 
local 
test 











在 建立 连接 之 初 ， 无 法 在 名 为 test 的 数据 库 中 进行 
任何 读 写 操作 。 以 用 户 read_user 的 身份 通过 验 
证 后 ， 可 运行 简单 的 find 指 令 。 尝 试 写 入 数据 

时 ， 却 因 没 有 权限 而 再 次 操作 失败 。 用 
Ptest_user 在 创建 时 并 没有 被 设 定 为 只 读 用 
户 ， 因 此 可 正常 进行 读 写 操作 。 但 用 
户 test_user 并 非 管理 员 用 户 ， 因 此 不 能 通过 执 
行 show dbs 指 令 来 列 出 所 有 数据 库 。 以 上 操作 


























































































































































































































中 的 最 后 一 步 是 管理 员 用 户 root 的 身份 验 
证 ，root 可 对 任 一 数据 库 进 行 操作 。 
































18.1.2 ”配置 身份 验证 














启用 身份 验证 后 ， 客 户 端 必须 登录 才能 进行 读 
写 。 然 而 ， 在 MongoDB 中 有 一 点 值得 注意 : 在 
admin 数 据 库 中 建立 用 户 前 ， 服 务 器 上 的 ”本 地 “ 客 
户 端 可 对 数据 库 进 行 读 写 。 


一 般 情 况 下 这 不 是 问题 ， 正 常 新 建 管理 员 用 户 并 
进行 身份 验证 即 可 。 唯一 的 例 多 情况 则 与 分 片 有 
关 。 分 片 时 ， 数 据 库 admin 会 被 保存 在 配置 服务 
器 〈config server) 上 ， 所 以 分 片 中 的 mongod H 
至 并 不 知道 它 的 存在 。 因 此 ， 在 它们 看 来 ， 它 们 
虽然 开启 了 身份 验证 但 却 不 存在 管理 员 用 户 。 于 
是 ， 分 片 中 会 允许 一 个 本 地 的 〈local) 客户 端 无 
需 喘 份 验证 便 可 读 写 数据 。 


希望 这 不 会 成 为 一 个 问题 ， 将 网 络 配置 为 只 允许 
客户 端 访问 mongos 进 程 即 可 。 不 过 ， 如 担心 客户 
端 在 分 片 的 本 地 上 运行 ， 不 通过 mongos 进 程 而 直 
接连 接 到 分 片 的 话 ， 可 在 分 片 中 添加 管理 员 用 
Hs 


注意 ， 我 们 并 不 想 让 分 片 集群 知道 这 些 管 理 员 用 












































































































































































































































































































































户 的 存在 ， 因 为 已 经 存在 了 一 个 admin 数 据 库 。 
在 分 片上 建立 的 admin 数 据 库 仅 供 我 们 使 用 。 要 
进行 这 一 操作 ， 可 连接 到 每 个 分 片 的 主 节 点 ， 然 
后 运行 addUser() 函 数 : 





















































> db.addUser("someUser", "theirPassword") 























应 保证 新 建 用 户 的 副本 集 是 作为 集群 中 的 分 片 存 
在 的 。 如 果 新 建 了 管理 员 用 户 ， 并 尝试 使 用 
addshard 命 令 将 mongod 作 为 分 片 加 入 集 t, 2 
发 现 这 一 命令 无 法 执行 〈 因 为 集群 中 已 经 存在 J 
名 为 admin 的 数据 库 ) 。 


























































































































18.1.3 身份 验证 的 工作 原理 























数据 库 中 的 用 户 是 作为 文档 被 储存 在 

其 syste.users 集 合 中 的 。 这 种 用 以 保存 用 户 信 
息 的 文档 结构 是 {user : username, readOnly 
: true, pwd : password hash}。 其 ! 
password hash 是 基于 username 和 密码 生成 的 
散 列 值 。 


了 解 了 用 户 身份 信息 的 存储 位 置 与 方法 后 ， 可 方 
便 地 对 其 进行 管理 。 例 如 ， 要 删除 一 个 用 户 ， 只 
需 从 systemusers 集 合 中 删除 这 一 用 户 的 文档 即 
可 。 



















































































































































































> db.auth("test_user", 
1 
> db.system.users.remove({"user" : "test_u 
> db.auth("test_user", 
0 


"efgh"); 


"efgh"); 



































户 进行 身份 
行 authe 
这 意味 着 只 要 


或 遇 到 故障 而 切换 到 另 一 节点 ， 
的 用 户 也 需 在 
作 应 由 驱动 程 











验证 时 ， 服 务 器 可 通过 绑 定 执 





nticate 命 令 的 连接 ， 跟 踪 身 份 验证 。 


























驱动 程序 或 其 他 工 

















具 使 用 了 连接 池 
已 经 过 身份 验证 









































新 的 连接 上 重新 进行 认证 。 这 一 操 














序 在 后 台 进 行 处 理 。 














18.2 ”建立 和 删除 索引 


ASS 





深入 介 绍 这 些 命令 的 运行 过 程 。 
库 最 耗费 资源 的 操作 之 一， 所 以 
立 索引 。 


建立 索引 需 MongoDB 查 找 集合 中 每 
索引 的 字段 〈 或 正 要 建立 索引 的 字段 ) ， 然 后 对 
不 出 所 料 ， 随 着 集合 体积 








HJ, 








第 5 章 介绍 了 用 于 建立 索引 的 命令 ， 但 没有 











建立 索引 是 数据 
应 小 心地 安排 建 




















一 个 文档 内 被 














查找 到 的 值 进行 排序 。 
的 增长 ， 该 操作 消耗 非常 大 。 因 











应 使 用 对 
































Ik, ERI 


生产 服务 器 影响 最 小 的 方式 。 


18.2.1 在 独立 的 服务 器 上 建立 索引 





在 独立 的 服务 器 上 ， 可 在 空闲 时 间 于 后 台 建 立 索 
引 。 除 此 之 外 ， 没 有 什么 更 好 的 办 法 来 减轻 建立 
索引 所 需 的 性 能 开销 。 在 后 台 建 立 索 引 ， 可 利用 


ayes 


background: true 参 数 运 行 ensureIndex 命 



























































> db.foo.ensureIndex ({"someField" : 1}, {"background' 























任何 类 型 的 索引 均 可 在 后 台 完 成 建立 。 


在 前 台 建 立 索 引 要 比 在 后 台 建 立 索 引 耗 时 少 ， 但 
在 索引 建立 期 间 会 锁定 数据 库 ， 从 而 导致 其 他 操 
作 无 法 进行 数据 读 写 。 而 后 台 在 建立 索引 期 间 ， 
则 会 定期 释放 写 锁 ， 从 而 保证 其 他 操作 的 运行 。 

这 意味 着 后 台 建 立 索 引 耗 时 更 长 ， 尤 其 是 在 频繁 
进行 写 入 的 服务 器 上 。 但 后 台 服 务 器 在 建立 索引 
期 间 ， 可 继续 为 其 他 客户 端 提 供 服 务 。 
























































































































































18.2.2 ”在 副本 集 上 建立 索引 


























副本 集 上 建立 索引 最 简单 的 方式 ， 即 在 主 节点 
建立 索引 ， 然 后 等 待 其 被 复制 到 其 他 备份 节 
。 在 较 小 的 集合 中 ， 这 一 操作 不 会 造成 太 大 的 
响 。 






























































S 





如 集合 较 大 ， 则 会 出 现 所 有 备份 节点 同时 开始 建 
立 索 引 的 情况 。 突 然 间 所 有 备份 节点 都 无 法 被 客 
户 端 读 取 了 ， 同 时 可 能 也 无 法 及 时 进行 同步 复 
制 。 因 此 ， 对 于 较 大 的 集合 ， 推 荐 采用 的 方式 
是 : 









































hs 


. 关闭 一 个 备份 节点 ; 

2. 将 其 作为 独立 的 节点 启动 ， 如 第 6 章 描 述 的 
那样 ; 
在 这 一 服务 器 上 建立 索引 ; 
重新 将 其 作为 成 员 加 入 副本 集 ; 
5. 对 每 个 备份 节点 执行 同样 的 操作 。 


完成 以 上 操作 后 ， 只 剩 主 节 点 还 没有 建立 索引 。 
现在 有 两 种 选择 : 


。 于 后 台 在 主 节点 中 建立 索引 〈 这 会 对 主 节 点 
的 性 能 造成 压力 ) ; 

e 关闭 主 节点 ， 并 执行 以 上 步骤 1~4， 像 在 次 
成 员 中 一 样 ， 在 主 节点 上 建立 索引 。 该 方式 
需 数据 库 停 运 一 次 ， 应 权衡 利 闵 进 行 选择 。 


也 可 以 使 用 这 种 隔离 创建 技术 ， 在 没有 被 配置 为 
建立 索引 的 副本 集 内 的 成 员 上 建立 索引 ， 即 使 用 
了 buildIndexes: false 选 项 。 方 法 是 将 其 作 
为 独立 服务 器 启动 ， 建 立 索 引 ， 并 重新 加 入 副本 
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be 












































































































































集 。 


如 果 由 于 某 种 原因 无 法 使 用 以 上 方法 ， 则 需 计 划 
在 空闲 时 间 〈 上 晚上、 假期、 周末 等 ) 来 建立 新 的 
索引 。 



























































18.2.3 在 分 片 集 群 上 建立 索引 











在 分 片 集群 上 建立 索引 ， 与 在 副本 集中 建立 索引 
的 步 又 相同 ， 不 过 需要 在 每 个 分 片上 分 别 建立 一 
次 。 


于 先 ， 关 闭 平 衡器 。 然 后 按照 上 一 节 中 的 步骤 ， 
依次 在 每 一 个 分 片 中 进行 操作 ， 即 把 每 个 分 片 当 
作 一 个 单独 的 副本 集 。 最 后 ， 通 过 mongos 运 
行 ensureIndex， 并 重新 启动 平衡 器 。 


只 有 在 现存 分 片 中 添加 索引 时 才 需 这 样 做 ， 新 的 
分 片 会 在 开始 接收 集合 数据 块 时 抓 取 集 合 中 的 索 


















































































































































18.2.4 删除 索引 














如 不 再 需要 某 索 引 ， 可 使 用 dropIndexes 命 令 并 
指定 索引 名 来 删除 索引 。 碍 询 system.indexes 集 合 























驱动 器 间 也 会 存在 些许 差异 : 














找 出 索引 名 ， 即 使 是 自动 生成 的 索引 名 ， 在 不 同 








> db.runCommand({"dropIndexes" : 


foo", "i 

















的 所 有 索引 : 


只 需 将 "*" 作 为 jndex 的 值 ， 即 可 删除 一 个 集合 中 








> db.runCommand({"dropIndexes" : " 











但 这 种 方法 无 法 删除 id 索引 。 只 有 删除 整个 集 








合 才能 删除 掉 该 索引 。 删 除 集合 中 的 全 部 文档 不 








会 对 索引 产生 影响 ， 新 文档 插入 后 索引 仍 可 正常 








增加 。 





18.2.5 ”注意 内 存 溢出 杀手 











Linux 的 内 存 溢出 杀手 (OOM Killer, out-of- 
memory killer) 负责 终止 使 用 过 多 内 存 的 进程 。 
考虑 到 MongoDB 使 用 内 存 的 方式 ， 除 了 在 建立 索 
































引 的 情况 下 ， 它 通常 不 会 遇 到 这 种 问题 。 如 在 建 











立 索 引 时 ，mongod 突 然 消 失 ， 请 检 


















































-A 





(swap) 空间 可 避免 此 类 情况 。 如 盾 



































H 























查 /varlog/messages 文 件 ， 其 中 记录 了 OOM Killer 
的 输出 信息 。 在 后 台 建 立 索 引 或 增加 交换 


机 器 的 管 


里 员 权 限 ， 可 将 MongoDB 设 置 为 不 可 被 OOM 











Killer 终 止 。 更 多 信息 请 参见 23.5.2 节 。 
18.3” 预 热 数 据 


重启 机 器 或 启动 一 台新 的 服务 器 ， 会 耗费 一 段 时 
间 供 MongoDB 将 所 有 所 需 数据 从 磁盘 中 载 入 内 
存 。 如 对 于 性 能 的 需求 很 高 ， 要 求 数据 必须 出 自 
内 存 中 ， 则 将 新 服务 器 上 线 ， 并 等 待 应 用 程序 载 
入 所 有 所 需 数据 ， 这 会 是 一 项 艰巨 的 工作 。 


有 几 种 方式 可 在 服务 器 正式 上 线 之 前 将 数据 载 入 
内 存 ， 以 避免 在 应 用 运行 时 带 来 麻烦 。 















































































































































“重启 MongoDB 会 改变 内 存 中 的 内 

容 。 内 存 是 由 操作 系统 进行 管 里 的 ， 而 操作 系 
统 不 会 将 数据 清除 出 内 存 ， 除 非 有 其 他 程序 需 
要 使 用 此 段 内 存 空间 。 因 此 ， 如 果 mongod 进 程 
需要 重启 ， 应 不 会 影响 内 存 中 的 数据 。〔 然 

而 ，mongod 会 报告 较 低 的 常 驻 内 存 值 ， 直 到 它 
有 机 会 向 操作 系统 请 求 所 需 的 数据 。) 





























































































































18.3.1 将 数据 库 移 至 内 存 











如 需 将 数据 
工 























库 移 








至 内 存 中 ， 
\， 从 而 在 启动 mongod 前 载 入 数据 文件 : 


可 使 用 











UNIX! 











的 dd 











> do 


> done 





$ for file in /data/db/brains.* 


> dd if=$file of=/dev/null 








brains 














将 /data/db/brains.* 


整个 数据 目 
内 





存 容量 足够 


ae IIA Bd 
的 话 ) 。 
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REH 


换 为 /data/db/* 可 
EE) 载 入 内 存 (假设 
0 将 一 个 或 一 
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组 数据 库 载 





Æ 








入 内 存 ， 
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其 中 一 些 数 








况 下 ， 可 使 | 











REE RIZ 
Imongod 启 动 





果 操 作 系统 发 现 内 存 中 已 经 存 1 
> BEAT LASER 





件 








下 一 节 
BRA TE. 


村， 会 向 操作 系统 请 求 数据 文件 。 





除 

















的 内 存 又 要 比 实际 内 存 大 的 话 ， 
会 立即 被 清 





出 内 存 。 
FP 讲 到 的 几 种 方法 ， 以 而 将 


在 这 种 


情 














如 











然而 ， 只 有 在 整个 数据 库 可 以 装 入 内 





访问 





在 了 这 





此 mongod。 








些 数 据 文 


存 中 时 ， 这 








一 技术 才能 发 挥 作用 。 
ao KATEL 
热 。 











人 否则， 



































可 使 


JAFA 
| 粒度 的 〈fine-grained) 预 


介绍 的 








18.3.2 ”将 集合 移 至 内 存 











MongoDB 提 供 了 touch 命 令 来 预 热 数据 。 启 动 
mongod (也 许 在 男 一 个 端口 上 ， 或 关闭 防火 墙 对 
它 的 限制 ) ， 对 一 个 集合 使 Out 从 而 
将 其 载 入 内 存 : 









































> db.runCommand({"touch" : "logs", "data" 








这 一 操作 会 将 logs 集 合 中 的 所 有 文档 和 索引 载 入 
内 存 。 可 指定 内 存 只 载 入 文档 或 只 载 入 索引 。 
touch 操 作 结束 后 ， 可 允许 应 用 访问 MongoDB。 


然而 ， 一 整个 集合 《即使 只 有 索引 ) 依然 可 占用 
很 大 的 空间 。 例 如 ， 应 用 可 能 只 需要 一 个 索引 或 
一 小 部 分 文档 在 内 存 中 。 在 这 种 情况 下 ， 需 对 数 
据 进 行 自 定义 预 热 。 






















































































18.3.3” 自 定义 预 热 











更 复杂 的 预 热 ， 可 上 自 定义 预 热 脚本 。 以 
些 常见 的 预 热 需求 和 解决 方案 。 


。 加 载 一 个 特定 的 索引 
假设 索引 必须 处 于 内 存 中 ， 如 {"friends" 





8 


进行 
— Hk 





yak 
下 





1, "date" : 1}。 可 进行 覆盖 查询 (covered 
query， 参 见 $.1.2 节 ) ， 从 而 将 该 索引 载 入 内 存 
H., 











> db.users.find({}, {"_id" : ©, "friends" 
. hint({"friends" : 1, "date" : 1}).expl 


























以 上 explain 命 令 会 强制 mongod 遍 历 所 有 结果 。 
必须 通过 find 命 令 的 第 二 个 参数 指定 只 返回 被 索 
引 字 段 ， 否 则 这 一 查询 同样 会 将 所 有 文档 加 载 入 
内 存 〈 也 许 这 就 是 我 们 想 要 的 结果 ， 但 应 注意 这 
一 点 ) 。 注 意 ， 该 操作 总 是 会 把 无 法 被 覆盖 
(covered) 的 文档 和 索引 加 载 入 内 存 ， 如 多 值 索 
引 Cmultikey index) o 


。 加载 最 近 更 新 的 文档 


如 在 更 新 文档 时 同时 更 新 了 日 期 字段 上 的 索引 ， 
可 通过 查询 最 近日 期 来 加 载 最 近 更 新 的 文档 。 


如 没有 日 期 字段 上 的 索引 ， 查 询 后 会 将 集合 中 的 
所 有 文档 加 载 入 内 存 ， 所 以 就 不 必 使 用 此 方法 
了 。 在 缺少 日 期 字段 的 情况 下 ， 如 主要 关心 的 是 
最 近 插 入 的 文档 ， 可 使 用 _id 字 段 作 为 蔡 代 参 
见 下 列 内 容 ) 。 












































































































































































































































。 加 载 最 近 创建 的 文档 


如 _id 字 段 使 用 ObjectIdsIf 类 型 ， 则 可 利用 最 
近 创 建文 档 内 的 时 间 戳 进行 文档 查询 。 如 希望 查 
找 上 星期 建立 的 所 有 文档 ， 可 建立 一 个 比 所 有 要 
查找 的 文档 建立 时 间 都 要 早 的 _id: 


> lastWeek = (new Date(year, month, day)). 
1348113600 



































































































































将 year、month 和 date 进 行 适当 替换 ， 返 回 的 结 
果 是 以 秒 为 单位 的 日 期 值 。 现 在 需要 使 用 此 日 期 
建立 一 个 0bjectId 类 型 的 值 。 首 先 ， 将 其 转换 
成 一 个 十 六 进 制 字符 串 ， 然 后 在 后 面 加 上 16 个 
0: 











































































































> hexSecs = lastWeek.toString(16) 

505a94c0 

> minId = ObjectId(hexSecs+"00000000000000 
ObjectId("505a94c00000000000000000") 




















现在 只 需 对 其 进行 查询 : 














> db.logs.find({"_id" : {"$gt" : minId}}). 

















该 操作 会 加 载 自 上 星期 以 来 的 所 有 文档 (以 及 
_id 索 引 的 一 部 分 右 子 树 ) 。 




















。 重 放 应 用 














使 用 记录 

















MongoDB 提 供 











有 名 为 诊 








启用 诊断 日 有 
时 使 ) 
水 。 
水 : 








JÒ 



































Wr H as 
diagnostic log) 的 功能 来 记录 和 
aol BYP 
的 方式 来 获 
在 mongo shell! 


FE 能 损失 ， 所 以 最 好 通过 
得 一 份 “ 有 代表 性 
运行 以 下 命令 来 记录 操作 流 








忘 (diaglog, 
可 放 操 作 流水 。 














til 





的 操作 流 








> db.adminCommand({"diagLogging" 





2}) 














24 
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中 参数 值 为 2 意味 着 
己 录 写 入 操作 ， 为 3 时 





记录 读 取 操作 。 


该 值 为 1 时 





读 写 都 会 进行 记录 CR 








认 
ia) 


AB 


值 为 0， 意 味 着 不 进行 
己 录 写 入 操作 ， 





大 








记录 ) 。 
为 在 


我 们 可 能 不 希 
重 放 操 作 流 水 时 ， 该 操 
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现在 i 
从 而 令 诊断 
放 在 诊断 日 志 志 


致 新 成 员 


aw 























Fmongod 运 行 所 需 








REKS 


写 入 。 








志 记 录 操 


的 时 间 并 向 
EKo 








生成 的 文件 








其 发 送 请 求 ， 
读 取 操作 会 被 存 
牛 位 于 数据 目 























中 ， 该 文 


录 下 。 完 成 后 将 diagLogging 的 值 重 设 为 0: 


> db.adminCommand({"diagLogging" 


0}) 























要 想 使 用 


动 新 的 








服务 器 





> 


诊断 文件 ， 可 从 该 文件 所 在 的 服务 器 启 
运行 以 下 命令 : 





[s nc hostname 27017 | 

















按 需 对 其 中 的 人 P 地 址 、 端 口 和 数据 目录 进行 
换 。 以 上 命令 会 将 诊断 文件 中 记录 的 操作 作为 普 
通 请 求 发 送 到 hostname:27017 处 。 


注意 ， 诊 断 日 志 会 记录 开启 诊断 日 志 的 命令 ， 所 
以 ， 重 放 完成 后 ， 需 登录 服务 器 并 关闭 诊断 日 志 
《我 们 可 能 也 想 删除 从 重 放 中 生成 的 诊断 文 

件 ) 3 


这 些 技术 可 结合 起 来 使 用 。 例 如 ， 可 在 重 放 诊 断 
记录 的 同时 加 载 若干 索引 ; 如 果 没 有 过 到 磁盘 IO 
瓶颈 的 话 ， 也 可 以 同时 进行 这 些 操作 ;或 者 也 可 
以 通过 多 个 shell 或 者 startParallelShell ( 启 
动 并 行 shell) 命令 (如 果 shell 在 mongod 本 地 的 
话 ) 来 进行 操作 : 































































































































































































> pl = startParallelShell("db.find({}, {x:1}) -hint ({ 
> p2 = startParallelShell("db.find({}, {y:1}) -hint ({ 





> p3 = startParallelShell("db.find({}, {z:1}) -hint ({ 








将 port 替 换 为 mongod 所 在 的 端口 值 。 
18.4 压缩 数据 
MongoDB 会 占用 大 量 的 磁盘 空间 。 有 时 ， 大 量 数 



















































































据 被 删除 或 更 新 后 ， 会 在 集合 中 产生 碎片 。 如 数 
据 文件 中 有 很 多 空闲 空间 ， 但 | 于 这 些 独立 的 空 
闲 区 块 过 小 ， 从 而 使 得 MongoDB 无 法 对 其 进行 重 
nd ee 在 这 种 情况 下 ， 会 在 


Fri Oct 7 06:15:03 [conn2] info DFM: :findA 
skipping ahead. ns:bar.foo 








































































































该 信息 本 身 是 无 害 的 。 然 而 ， 这 意味 着 某 一 整个 
区 段 (extent〉 中 不 包含 任何 文档 。 为 消除 空 区 
段 ， 并 高 效 重 整 集合 ， 可 使 用 compact 命 令 : 












































> db.runCommand({"compact" : "collName"}) 








压缩 操作 会 消耗 大 量 资源 ， 不 应 在 mongod 疝 客户 
端 提 供 服务 时 计划 压缩 操作 。 推 荐 做 法 类 似 于 建 
立 索 引 时 的 做 法 ， 即 在 每 个 备份 节点 中 对 数据 执 
然后 关闭 主 节 点 ， 进 行 最 后 的 压缩 
RIE. 


在 一 个 备份 节点 中 运行 压缩 操作 ， 会 使 其 进入 恢 
复 状 态 (recovering state) ， 即 它 会 对 读 取 请 求 返 
回 错误 ， 亦 无 法 作为 一 个 同步 源 。 压 缩 操 作 结束 
后 ， 其 状态 会 重新 变 为 备份 节点 (secondary 
state) 。 










































































压缩 操作 会 将 文档 
的 间隔 参数 默认 为 
使 用 额外 的 参数 来 











尽 可 能 地 安排 在 一 起 ， 文 档 间 


1。 如 需 更 大 的 间隔 参 


指定 它 : 


HÆ B: 





数 ， 可 








> db.runCommand ({"compact" 


: "collName", 





"paddingFact 





间隔 参 
不 会 持续 生效 ， 只 
新 安排 文档 时 的 间 
重新 返回 之 前 的 值 。 


压缩 操作 并 不 会 减 
作 只 是 将 所 有 文档 























数 最 小 为 1， 最 大 为 4。 对 | 








隔 。 























司 隔 参数 的 设 定 
会 影响 压缩 过 程 中 MongoDB 重 
压缩 完成 后 ， 间 隔 参 数 会 











少 集合 占用 的 磁盘 空间 ， 该 操 














都 安排 在 集合 








样 当 集 合 继续 增 大 





时 就 











分 。 因 此 ， 压 缩 操 
时 措施 ， 它 不 会 减 
大 小 $ 











须 拥 有 和 当前 数据 
间 。 这 时 
见 原因 就 是 机 器 的 
挂 载 其 他 磁盘 ， 则 
即 repair MER H 
装 的 驱动 )。 


















































但 可 使 MongoDB 不 


可 通 过 运行 repair (修复 ) 命令 
司 。repair 命 令 会 对 所 有 数 于 


常 是 个 大 问 








作 只 是 在 磁盘 空间 





少 MongoDB 所 


开始 部 分 


这 





可 以 使 用 后 画 


[的 空余 











不 足 时 的 临 
的 磁盘 空间 


mj 















































必需 要 分 


来 回收 磁盘 空 
EEIT h 





配 新 的 空间 。 

















i), 所 以 必 


文件 一 样 大 小 的 空余 磁盘 空 





题 








， 因 为 运行 repair 灵 








的 最 党 











磁盘 空间 


可 指定 








不 多 了 。 
一 个 修复 路 径 ， 





| 文件 时 所 使 朋 


然而 ， 如 能 


日 的 目录 (新 安 











由 于 repair 操 作 会 完全 复制 所 有 数据 ， 因 此 可 随 
时 中 断 该 操作 而 不 影响 原始 数据 集 。 如 在 repair 
操作 的 过 程 中 遇 到 问题 ， 可 删除 repair 产 生 的 临 
时 文件 而 不 会 影响 到 数据 文件 。 


在 启动 mongod 时 使 用 - - repair 选项 〈 如 需要 ， 
还 可 使 用 --repairpath 选 项 ) 来 进行 修复 。 


































































































可 以 在 shell 中 调用 db .repairDatabase() 来 修复 
数据 库 。 


18.5 ”移动 集合 


可 使 用 renameCollection 命 令 来 重 命名 集合 。 
这 一 命令 无 法 在 数据 库 间 移动 集合 ， 但 可 更 改 集 
合 名 。 无 论 重 命名 的 集合 大 小 ， 该 操作 都 基本 上 
是 瞬间 完成 的 。 在 繁忙 的 系统 上 ， 这 一 操作 会 耗 
费 几 秒 钟 ， 但 在 生产 环境 中 运行 可 不 用 担心 性 能 
的 消耗 。 


> db.sourceColl.renameCollection ("newName") 

























































































执行 这 一 命令 时 可 传 入 第 二 个 参数 ， 从 而 决定 当 
名 为 newName 的 集合 已 经 存在 时 应 如 何 处 理 。 该 
参数 为 true 时 ， 会 删除 名 为 newName 的 集合 ; 

为 false 时 ， 则 会 抛 出 错误 。 后 者 是 这 一 参数 的 












































默认 值 。 











要 想 在 数据 库 间 移 动 集合 ， 必 须 进行 转 储 
(dump ) 和 恢复 〈restore) 操作 ， 或 手动 复制 集 
合 中 的 文档 (使 用 find 命 令 ， 遍 历 集合 中 的 所 有 
文档 ， 从 而 将 其 插入 到 新 的 数据 库 中 〉。 














bal 


















































可 使 用 cloneCollection 命 令 将 一 个 集合 移动 到 
另 一 个 不 同 的 mongod 中 。 

















> db.runCommand({"cloneCollection" : "collName", "frq 
































CE 法 使 用 cloneCollection 命 令 在 mongod 中 移动 
集合 ， 这 一 命令 只 能 用 于 服务 器 间 的 集合 移动 。 

18.6 ”了 预 分 配 数据 文件 

如 知道 mongod 有 具体 需要 哪些 数据 文件 ， 可 运行 以 
下 脚本 ， 从 而 在 应 用 上 线 前 预 分 配 数据 》 
能 确定 数据 库 和 操作 记录 的 大 小 ， 至 少 

间 以 内 的 大 小 ， 这 一 方法 则 尤其 有 用 。 


#!/bin/bash 































































































# 确保 传 入 数据 库 名 
if test $# -lt 2 || test $# -gt 3 
then 





echo "$0 <db> <number-of-files>" 
fi 


db=$1 
num=$2 


for i in {@..$num} 
do 
echo "Preallocating $db.$i" 
head -c 2146435072 /dev/zero > $db.$ 


done 














将 以 上 代码 存 入 一 个 文件 中 《比如 说 preallocate 
文件 ) ， 并 将 文件 设置 为 可 执行 文件 。 切 换 至 数 
据 目 录 ， 按 需 执 行 以 下 脚本 ， 分 配 数据 文件 : 


$ # create test.0-test.100 
$ preallocate test 100 

$ 
$ # create local.@-local.4 
$ preallocate local 4 










































































数据 库 启 动 后 首次 访问 数据 文件 时 ， 不 能 对 其 中 
的 任何 文件 进行 删除 。 例 如 ， 如 分 配 数据 文件 
test.0~test100， 而 启动 数据 库 后 却 发 现 只 需 使 用 
test.0~test.20， 这 时 我 们 不 应 删除 test.21~test.100 
的 文件 。 只 要 MongoDB 意 识 到 这 些 文件 的 存在 ， 
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文件 





删除 后 则 会 导致 MongoDB 发 4 

















第 19 章 ”持久 性 


持久 性 〈durability) 是 操作 被 提交 后 可 持久 保存 
在 数据 库 中 的 保证 。 从 完全 没有 保障 到 完全 保证 
持久 性 ，MongoDB 可 高 度 配置 与 持久 性 相关 的 设 
定 。 本 章 内 容 包 括 : 


。 MongoDB 如 何 保 证 持久 性 ; 
如 何 配置 应 用 和 服务 器 ， 从 而 获得 所 需 的 持 
久 性 级 别 ; 

。 运行 时 关闭 日 记 系 统 (journaling) 可 能 带 来 
的 问题 ; 

MongoDB 不 能 保证 的 奸 


如 磁盘 和 软件 运行 正常 ， 则 MongoDB 能 够 在 系统 
骨 溃 或 强制 关闭 后 ， 确 保 数据 的 完整 性 。 


注意 ， 关 系 型 数据 库 通常 使 用 持久 性 一 词 来 描述 
数据 库 事 务 〈transaction) 的 持久 保存 。 由 于 
MongoDB 并 不 支持 事务 ， 因 此 该 词义 在 这 里 有 些 
许 不 同 。 


19.1 日 记 系 统 的 用 途 


MongoDB 会 在 进行 写 入 时 建立 一 条 日 志 
(journal) ， 日 记 中 包含 了 此 次 写 入 操作 有 具体 更 



















































































项 。 
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i 


















































































































































改 的 磁盘 地 址 和 字 节 。 因 此 ， 一 旦 服务 器 突然 停 


机 ， 可 在 启动 时 对 


























记 进 行 重 放 (replay) ， 从 





而 重新 执行 那些 停机 前 没 能 够 刷新 (flush〉 到 磁 





盘 的 写 入 操作 。 





























数据 文件 默认 每 60 秒 刷新 到 磁盘 一 次 ， 因 此 日 记 
文件 只 需 记录 约 60 秒 的 写 入 数据 。 日 记 系 统 为 此 



































a ee 














在 /data/db/journal 














af 
vyTo 

















文件 了 ) 。 





WR Rai, REH 








牛 名 为 j.0、_j.1 








长 时 间 运 行 MongoDB 后 ， 日 


记 目 录 中 会 出 现 类 似 








_j.6217、_j.6218 和 j.6219 的 文件 。 这 些 是 当前 的 
日 记 文 件 。 文 件 名 中 的 数字 会 随 着 MongoDB 运 行 
时 间 的 增长 而 增 大 。 数 据 











WRH HWX 














ESRAR AKEH 














关闭 后 就 不 再 需要 这 些 


























Hkill -9 命令 强制 终止 








数据 库 的 运行 ，mongod 会 在 启动 时 重 放 日 记 文 
































牛 ， 同 时 会 显示 出 大 量 的 校 验 信息 。 这 些 信息 元 


长 且 难 懂 ， 但 其 存在 说 明 一 切 都 在 正常 运行 。 可 
在 开发 时 运行 ki11 -9 命 人 Nae sioner ar 








重新 启动 ， 这 样 在 生 


























， 如 果 发 生 相同 状 

















况 ， 也 会 明白 此 时 显示 哪些 信息 是 正常 的 。 





MongoDB 默 认 每 隔 100 毫 秒 ， 或 是 写 入 数据 达到 
若干 兆 字 节 时 ， 便 会 将 这 些 操 作 写 入 日 记 。 这 意 
味 着 MongoDB 会 成 批量 地 提交 更 改 ， 即 每 次 写 入 
不 会 立即 刷新 到 磁盘 。 不 过 在 默认 设置 下， 系统 
发 生 崩 演 时 ， 不 可 能 丢失 间隔 超过 100 毫 秒 的 写 
入 数据 。 


然而 ， 对 于 一 些 应 用 而 言 ， 这 一 保障 还 不 够 牢 
回 ， 因 此 可 通过 若干 方式 来 获得 更 强 有 力 的 持久 
性 保证 。 可 通过 向 getLastError 传 递 j 选 项 ， 
来 确保 写 入 操作 的 成 功 。getLastError 会 等 待 
前 一 次 写 入 操作 写 入 到 日 记 中 ， 而 日 记 在 下 一 批 
HESAN, RREKO (MEOE 

秒 ) : 

































































































































































> db.foo.insert({"x" : 1}) 
> db.runCommand({"getLastError" : 1, "j" : 
> // The {"x" : 1} document is now safely 
































注意 ， 这 意味 着 如 果 在 每 次 写 入 操作 中 都 使 用 
"j" : true 选 项 ， 则 写 入 速度 实际 上 会 被 限 
制 为 每 秒 33 次 : 





























(1 次 /30 毫 秒 )x(1000 毫 秒 / 秒 )=33.3 次 / 秒 














通常 将 数据 刷新 到 磁盘 并 不 会 耗费 这 么 长 时 间 ， 
所 以 如 果 人 允许 MongoDB 对 大 部 分 数据 进行 批量 写 
入 而 非 每 次 都 单独 提交 ， 数 据 库 的 性 能 则 会 更 
好 。 然 而 ， 重 要 的 写 入 操作 还 是 会 经 常 选用 此 选 
项 。 
























































提交 一 次 号 入 操作 ， 会 同时 提交 这 之 前 的 所 有 号 
入 操作 。 因 此 ， 如 果 有 50 个 重要 的 写 入 操作 ， 可 
使 用 “普通 的 ”getLastError 〈 不 包括 j 选 项 ) ， 
而 在 最 后 一 次 写 入 后 使 用 含有 j 选 项 的 
getLastError。 如 果 成 功 的 话 ， 就 可 知道 所 有 
50 次 写 入 操作 都 已 安全 刷新 到 磁盘 上 。 


如 果 写 入 操作 含有 很 多 连接 ， 可 通过 并 发 写 入 ， 
来 减少 使 用 j 选 项 所 带 来 的 速度 开销 。 此 种 做 法 
可 增加 数据 吞吐 量 ， 但 也 会 增加 延迟 。 
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19.1.2 设 定 提交 时 间 间 隔 








另 一 个 减少 日 记 被 干扰 几率 的 选项 是 ， 调 整 两 次 
提交 间 的 时 间 间 隔 。 运 行 setParameter 命 令 ， 
设 定 journalCommitInterval 的 值 ( 最 小 为 2 毫 
秒 ， 最 大 为 500 毫 秒 ) 。 以 下 命令 使 得 MongoDB 
每 隔 10 毫 秒 便 将 数据 提交 到 日 记 中 一 次 : 












































> db.adminCommand({"setParameter" : 1, "jo 














也 可 使 用 命令 行 选项 -- 
journal Commit Taterval ee 届 定 这 一 值 。 


无 论 时 间 间 隔 设 置 为 多 少 ， 使 用 带 有 "j 
ht He CRS a 
来 的 三 分 之 


如 客户 端的 写 入 速度 超过 了 日 记 的 刷新 速度 ， 
mongod 则 会 限制 号 入 操作 ， 直 到 日 记 完 成 到 磁盘 
的 写 入 。 这 是 mongod 会 限制 写 入 的 唯一 情况 。 


19.2 关闭 日 记 系 统 


对 于 所 有 生产 环境 的 部 署 ， 都 推荐 使 用 日 记 系 

统 ， 但 有 时 我 们 可 能 需要 关闭 该 系统 。 即 使 不 附 
带 j 选 项 ， 日 记 系 统 也 会 影响 MongoDB 的 写 入 速 
度 。 如 果 写 入 数据 的 价值 不 及 写 入 速度 降低 带 来 
的 损失 ， 我 们 可 能 就 会 想 要 禁用 日 记 系 统 。 


禁用 日 记 系 统 的 缺陷 在 于 ，MongoDB 无 法 保证 发 
生 骨 省 后 数据 的 完整 性 。 在 没有 日 记 系 统 的 前 提 
下 ， 一 上 旦 发 生 户 溃 ， 那 么 数据 肯定 会 遭 到 损坏 ， 
从 而 需要 对 数据 进行 修复 或 蔡 换 。 这 种 情况 下 遗 
到 损坏 的 数据 不 应 继续 投入 使 用 ， 除 非 我 们 不 
在 乎 数据 库 会 突然 停止 工作 。 










































































































































































































































































如 果 和 希望 数据 库 在 崩溃 后 能 够 继续 工作 ， 有 以 下 





























儿 种 做 法 。 





19.2.1 替换 数据 文件 























这 是 最 佳 选择 。 删 除数 据 目录 中 的 所 有 文件 ， 








后 获取 新 文件 ， 可 从 备份 中 恢复 ， AARMEN 
的 数据 库 快 照 ， 如 果 是 副本 集成 员 的 话 ， 也 可 对 
















































































其 进行 初始 化 同步 。 如 果 是 一 个 数据 量 较 小 的 副 
本 集 ， 重 新 同步 可 能 是 最 好 的 选择 ， 即 先 停止 此 












































成 员 的 运行 《如 果 它 还 没有 停止 运行 的 话 ) ， 删 
除数 据 目 录 中 的 所 有 内 容 ， 然 后 重新 启动 它 。 











19.2.2 ”修复 数据 文件 

















成 员 ， 则 需 抢救 所 有 可 能 的 数 所 

































































=] 





十 o 


如 果 既 没有 备份 和 复制 ， 也 没有 副本 集中 的 其 他 





需 对 数据 库 使 

















一 个 ”修复 “工具 ， 修 复 实质 上 是 删除 所 有 受 损 
数据 ， 不 过 可 能 不 会 留 有 太 多 完好 的 数据 。 























mongod 自 带 了 两 种 修复 工具 ， 





种 是 mongod 内 置 


的 ， 另 一 种 是 mongodump 内 置 的 。mongodump 的 











修复 更 加 接近 底层 ， 可 能 会 找到 

















更 多 的 数据 ， 但 





耗 时 要 更 长 《而 另 一 种 自 带 的 修复 方式 也 不 见得 
很 快 ) 。 另 外 ， 如 使 用 mongodump 的 修复 ， 在 准 
























































备 再 次 启动 前 ， 依 然 需 要 恢复 数据 的 操作 。 


对 此 ， 应 根据 愿意 在 数据 恢复 中 消耗 的 时 间 长 短 
来 进行 决定 。 


要 使 用 mongod 内 置 的 修复 工具 ， 需 附带 -- 
repair 选 项 运行 mongod: 





















































$ mongod --dbpath /path/to/corrupt/data -- 














进行 修复 时 ，MongoDB 不 会 开启 27017 端 口 的 监 
听 ， 但 我 们 可 通过 查看 日 志 Cog) 的 方式 得 知 它 
正在 做 什么 。 注 意 ， 修 复 过 程 会 对 数据 进行 一 份 
完整 的 复制 ， 所 以 如 有 80 GB 的 数据 ， SUR 80 GB 
的 空闲 磁盘 空间 。 为 尽量 解决 这 一 问题 ， 修 复工 
有 具 提 供 了 - -repairpath 选 项 。 这 一 选项 允许 在 
主 磁盘 空间 不 足 时 挂 载 一 个 “紧急 驱动 器 "， 并 使 
j 它 来 进行 修复 操作 。- -repairpath 选 项 的 用 
法 如 下 : 



































































































































$ mongod --dbpath /path/to/corrupt/data \ 
> --repair --repairpath /media/external-hd 























如 果 修 复 过 程 被 强行 终止 ， 或 者 出 现 故障 《如 磁 
盘 空间 不 足 ) ， 至 少 不 会 使 情况 变 得 更 糟 。 修 复 
工具 将 所 有 的 输出 都 写 入 新 的 文件 中 ， 不 会 对 原 



















































































有 文件 进行 修改 。 
修复 时 变 得 更 糟 。 



































习 此 








原始 数 











居 文 件 不 会 比 开 始 


另 一 个 选择 是 使 用 mongodump 的 - -repair 选 项 ， 





就 像 这 样 : 








$ mongodump --repair 














这 些 选择 都 不 是 特别 好 ， 但 








mongod 重 新 运行 在 一 个 干净 的 数据 集 上 。 








19.2.3 ”关于 mongod.lock 文 件 











数据 目录 中 有 一 个 名 为 mongod. lock 的 特殊 文件 。 
该 文件 在 关闭 日 记 系统 运行 时 十 分 重要 (如 启 上 























了 日 记 系 统 ， 则 这 一 文件 不 





~ 





























得 知 上 一 次 是 异常 退出 的 。 

















如 果 mongod 监 测 至 








1 上 一 


次 是 异常 








它们 应 该 可 以 让 














会 出 现 ) 。 


退出 的 ， 

















止 再 启动 ， 这 样 我 们 就 会 








mongod. lock XAF K Ja z 














当 mongod 正 常 退出 时 ， 会 清除 mongod.lock 文 件 ， 
这 样 在 启动 时 ，mongod 就 会 得 知 上 一 
HHA. ABR, MORIAH 


次 是 正常 退 
F 没 被 清除 ，mongod 就 会 





则 会 村 

















会 意识 到 一 份 干 将 
到 


有 些 人 意识 





Jmongod 。 











FY 
































数据 副 
HER 


请 不 要 这 么 做 。 






































19.2.4 ”隐蔽 的 异常 退出 











通常 ， 在 启动 时 删除 这 一 文件 ， 意 味 着 我 们 不 知 
道 也 不 在 乎 数据 是 否 受 损 。 除 非 如 此 ， 
要 这 么 做 。 如 果 mongod.lock 文 件 阻 ] 
启动 ， 请 对 数据 进行 修复 ， 而 非 删除 该 文件 。 





否则 请 不 
上 了 mongod 的 


























“要 删除 锁 文 件 的 另 一 重要 原因 在 于 ， 我 们 甚至 


可 能 意识 不 到 这 是 一 次 异常 退出 。 
列 行 维护 。 初 始 化 脚本 应 负责 在 服 
务 器 关闭 之 前 关闭 mongod。 初 始 化 脚本 通常 会 先 
尝试 正常 关闭 程序 ， 但 如 在 若干 秒 后 依然 没有 关 


重启 机 器 进行 








闭 的 话 ， 则 会 ; 


上 ，MongoDB 完 全 可 能 耗费 30 秒 来 结束 运 
常 的 初始 化 脚本 不 会 等 人 PCIE XKH. 
常 退出 的 次 数 可 能 比 我 们 知道 的 要 多 得 























选择 强行 关闭 。 在 一 个 繁 民 








假设 我 们 需要 


























的 系统 














运行 ， IE 














19.3 MongoDB 无 法 保证 的 事项 
在 硬件 或 文件 系统 出 现 故障 等 情况 下 ，MongoDB 
无 法 保证 操作 的 持久 性 。 尤 其 是 在 硬盘 发 生 损 坏 
的 情况 下 ，MongoDB 根 本 无 法 保证 数据 


另外 ， 不 同 的 硬件 和 软件 对 于 持久 性 的 保障 可 能 














有 所 不 同 。 例 如 ， 一 些 破旧 的 硬盘 会 在 


















































AE, FE 








多 。 


安全 。 


写 入 操作 

















还 在 列队 中 等 待 之 际 ， 便 报告 称 写 入 成 功 









































统 崩溃 ， 数 据 就 可 能 会 发 生 丢 失 。 
































同 ，MongoDB 无 法 避免 硬件 或 文件 系统 导致 





























MongoDB 无 法 防止 这 一 层次 的 误 报 ， 如 果 此 时 系 


基本 上 ，MongoDB 的 安全 性 与 其 所 基于 的 系统 相 


的 数 











据 损 坏 。 可 使 用 副本 应 对 系统 问题 。 如 果 
器 发 生 了 故障 ， 还 有 另 一 台 在 正常 工作 。 


19.4 检验 数据 损坏 






































台 机 


可 使 用 validate 命 令 ， 检 验 集合 是 否 有 损坏 。 

















如 检验 名 为 foo 的 集合 ， 代 码 如 下 : 





> db.foo.validate() 


"extentCount" : 11, 
"datasize" : 75960008, 
"nrecords" : 1000000, 
"lastExtentSize" : 37625856, 
"padding" : 1, 
"firstExtentDetails" : { 
"loc" : "0:2000", 
"xnext" : "0:00", 





{ 
"ns" : "test.foo", 
"firstExtent" : "0:2000 ns:test.foo", 
"lastExtent" : "1:3eae666 ns:test.foo" 





"xprev" : "null", 


"nsdiag" : "test.foo", 
"size" : 8192, 
"firstRecord" : "@:20be", 
"lastRecord" : "0:3fa0" 


J 
"deletedCount" : 9, 
"deletedSize" : 31974824, 


"nIndexes" : 2, 

"keysPerIndex" : { 
"test.foo.$_id_" : 1000000, 
"test.foo.$str_1" : 1000000 

}, 

"valid" : true, 

"errors" : [ ], 

"warning" : "Some checks omitted for s 
option to do more thorough scan." 

"ok" : 1 





























需 重点 注意 的 是 结尾 附近 的 valid 字 段 ， 字 段 值 
为 true。 否 则 ， 输 出 内 容 中 会 包含 找到 的 数据 损 
坏 细节 。 









































输出 中 的 大 部 分 内 容 ， 是 有 关 集 合 的 内 部 结构 信 
忠 ， 于 调试 而 言 没有 太 大 用 处 。 更 多 有 关 集 合 内 
部 结构 的 内 容 ， 请 参见 附录 B。 





















































e firstExtent ( 首 区 段 ) 
该 集合 首 区 段 (extent) MHEG (disk 





offset) 。 本 例 中 位 于 文件 test.0 处 ， 字 节 偏 





























移 量 (byte offset) 为 0x2000。 


e lastExtent 〈 尾 区 段 ) 





该 集合 尾 区 段 的 偏 移 量 。 本 例 中 位 于 文件 


test.1 处 ， 字 节 1 


e extentCount 











m Et AYOx3eae000. 





该 集合 所 占 区 段 数量 。 





e lastExtentSize 




















最 近 分 配 区 段 的 字 节 数 量 。 区 段 大 小 随 集 合 








的 增长 而 增长 ， 





最 大 可 达 2GB。 


e firstExtentDetails 












































描述 集合 中 首 区 段 的 子 对 象 。 其 中 包含 指向 
相 邻 两 个 区 段 的 指针 〈xnext 和 xprev) 、 

区 段 的 大 小 〈 注 意 ， 它 比 尾 区 段 要 小 得 多 ， 
通常 首 区 段 是 很 小 的 ) ， 以 及 指向 区 段 中 第 























一 条 和 最 后 一 条 记录 (record) 的 指针 。 记 





录 是 真正 承载 着 文档 的 结构 。 








deletedCount 








该 集合 从 存在 至 今 ， 共 删除 的 文档 数目 。 








e deletedSize 

该 集合 中 空 SPA WIFE Cree list) ， 即 所 有 有 效 
空余 空间 的 大 小 。 不 仅 包 括 被 删除 文档 所 
的 空间 ， 还 包括 已 被 预 分 配给 该 集合 的 空 


hao 











S 











Ih 


















































validate 命 令 只 适用 于 集合 ， 而 不 适用 于 索 
引 。 因 此 我 们 通常 无 法 判断 索引 是 否 被 损坏 ， 除 
非 遍历 检查 一 i, 即 查 询 每 个 索引 在 集合 中 对 应 
的 文档 。 通 过 遍历 得 出 的 结果 即 可 判断 索引 是 否 
被 损坏 。 


如 果 程 序 提示 了 非法 的 BSON 对 象 (invalid 
BSONObj) ， 一 般 说 明 数 据 损坏 了。 最 糟糕 的 错 
误 则 是 提 到 了 pdfile 的 错误 。pdfile 可 以 说 是 
MongoDB 的 数据 存储 核心 ， 源 于 pdfile 的 错误 
基本 说 明 数 据 文件 已 经 损坏 了 。 


如 果 遇 到 了 数据 损坏 ， 则 可 在 日 
下 内 容 : 





















































































































































中 看 到 类 似 如 








GH 





Tue Dec 20 01:12:09 [initandlisten] Assert 
Invalid BSONObj size: 285213831 (0x870 
first element: _id: ObjectId('4e5efa45 
































如 果 显 示 的 第 一 个 元 素 已 经 被 废弃 ， 就 没什么 可 




















做 的 了 。 如 果 第 一 个 元 素 还 是 可 见 的 〈 如 上 例 中 
的 ObjectId) ， 也 许可 删除 损坏 文档 。 可 尝试 
运行 














> db.remove({_id: ObjectId('4e5efa454b4ae2 






































将 其 中 的 _id 蔡 换 为 日 志 中 看 到 的 对 应 _id。 注 
意 ， 如 果 数 据 损坏 影响 的 不 只 是 该 文档 ， 则 这 种 
技术 可 能 不 会 奏效 。 这 种 情况 下 ， 我 们 可 能 仍 需 
对 数据 进行 修复 。 


19.5 副本 集中 的 持久 性 


第 10 章 曾 讨论 过 副本 集中 的 投票 问题 ， 即 一 次 对 
副本 集 的 写 入 操作 ， 在 写 入 副本 集中 的 大 多 数 成 
员 中 之 前 ， 可 能 先 会 进行 回 滚 〈rollback) 。 可 将 
与 此 相关 的 选项 和 之 前 提 到 的 日 记 系统 的 选项 结 
合 起 来 使 用 : 


> db.runCommand({"getLastError" : 1, "j" 






























































is 






























































进行 这 一 操作 后 ， 可 保证 写 入 操作 写 入 到 了 主 节 
点 和 备份 节 点 中 ， 其 中 只 有 对 主 节 点 的 写 入 可 保 
证 持久 性 。 理 论 上 来 讲 ， 在 进行 写 入 到 记录 到 
记 内 的 100 旱 秒 时 间 内 ， 多 数 的 服务 器 同时 月 演 
也 是 有 可 能 的 ， 这 种 情况 下 数据 库 会 回 滚 到 当月 
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主 节 点 的 状态 RY o 虽然 这 是 一 种 极端 情 Uh» 但 也 说 
明 其 并 非 是 完美 的 。 遗憾 的 是 要 解决 这 一 问题 并 
不 简单 ， 但 目前 MongoDB 社 区 正 尝试 改变 这 一 情 
况 。 

































































服务 器 管理 


第 20 章 启动 和 停止 MongoDB 


我 们 在 第 2 章 中 学 习 了 有 关 启 动 MongoDB 的 基本 
命令 。 本 章 我 们 将 就 生产 环境 中 配置 MongoDB 的 




























































































重要 选项 展开 深入 的 学 习 ， 内 容 包 括 : 
。 常 用 选项 ; 

e 启动 和 停止 MongoDB; 

。 安 全 相关 选项 ; 

。 使 用 日 志 时 的 注意 事项 。 








20.1 从 命令 行 启动 


执行 mongod 程 序 即 可 启动 MongoDB 服 务 器 ， 
mongod 在 启动 时 可 使 用 许多 可 配置 选项 ， 
行 中 运行 mongod --help 可 列 出 这 些 选 项 。 下 列 
























































选项 十 分 第 用， 需 着 重 注意 。 


e --dbpath 
使 用 此 选项 可 指定 一 个 目录 为 数据 
默认 值 为 /data/db/〈 在 Windows 中 贝 


























| 














MongoDB 可 执行 文件 所 在 磁盘 卷 ! 



































K) 。 机 器 上 的 每 个 mongod 进 程 都 需要 属 


在 命令 




















录 。 其 
为 
的 \data\db 








于 自己 的 数据 目录 ， 即 若 在 同一 机 器 上 运行 
三 个 mongod 实 例 ， 则 需 三 个 独立 的 数据 目 
































录 。mongod 局 动 时 ， 会 在 其 数据 目录 中 创建 

一 个 mongod.lock 文 件 ， 以 阻止 其 他 mongod 进 
程 使 用 此 数据 目录 。 若 尝试 启动 男 一 个 使 用 
相同 数据 目录 的 MongoDB 服 务 器 ， 则 会 出 现 
错误 提示 : 










































































"Unable to acquire lock for 
lockfilepath: 
/data/db/mongod. lock." 


° Renee 

此 选项 用 以 指定 服务 器 监听 的 端口 号 。 

mongod ih #1127017 ， 除 其 他 
进程 外 ， 其 余 程 序 不 会 使 用 此 端口 。 若 要 在 
同一 机 器 上 运行 多 个 mongod 进 程 ， 则 需 为 它 
们 指定 不 同 的 端口 。 若 尝试 在 已 被 占用 的 端 
口 启动 mongod， 则 会 出 现 错误 提示 : 
"Address already in use for socket: 
@.0.0.0:27017" 
































































































































e --fork 


启用 此 选项 以 调用 fork 创 建 子 进程 ， 在 后 台 


运行 MongoDB。 
























































于 次 启动 mongod 而 数据 目录 为 空 时 ， 文 件 系 统 需 

















几 分 钟 时 间 分 配 数据 库 文件 。 预 分 配 结束 ， 








mongod 可 接收 连接 后 
此 ，fork 可 
LA 


Ab 
能 会 























必须 同时 局 ) 











e --logpath 
使 用 此 选项 ， 

















文件 ， ma 


发 
E 在 进行 上 
]- -1ogpath 选 项 。 

















所 有 输 
FE 在 命令 行 上 输 





生 挂 起 。 
HERE. 








父 进程 才 会 继续 运行 。 














可 查看 
































出 信息 wy 会 被 


TH o 


天 
志 中 的 最 新 














启用 --fork 选 项 时 ， 


eo 
Ke 


发 送 至 指 














选项 后 处 


|S 


目录 的 写 权限 ， 若 指定 文 
动 生成 一 个 文件 。 











文件 已 存在 ， 





选项 启 


牛 不 
































后 则 
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该 选项 可 


F, ARIA HKI 
志 ， 除 --logpath 选 项 外 ， 强烈 建议 
} ee 


将 每 个 数据 库存 放 在 






































日 志 条 











--directoryperdb 



































录 中 。 我 们 可 


到 不 同 的 磁盘 


JEEE 


























此 按 需 将 不 同 
。 该 选项 一 般 用 了 
副本 放置 于 单独 的 磁盘 上 


的 








单独 的 
数据 库 挂 载 


















































将 本 地 数 
， 或 在 磁盘 














空间 不 足 时 将 


oy 





数据 


将 频繁 操作 的 数据 





E, 而 将 不 常 




















Mm 
lio 总 


操作 数据 库 。 








> 该 选项 和 


页 能 


用 的 数 
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库 移 动 至 其 他 


EAE 也 可 











EERE 
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速度 














项 库 放 到 较 慢 的 磁盘 
使 我 们 在 今后 更 


较 快 的 磁盘 











加 灵活 地 


e --config 

额外 加 载 配置 文件 ， 未 在 命令 行 中 指定 的 选 
项 将 使 用 配置 文件 中 的 参数 。 该 选项 通常 用 
于 确保 每 次 重新 启动 时 的 选项 都 是 一 样 的 。 
详细 内 容 请 参见 20.1.1 节 。 


列 如 ， 要 在 后 人 台 启 动 一 个 服务 器 ， 监 昕 5586 端 
， KAH 出 信息 发 送 至 mongodb.log 文 件 
中 ， 可 运行 如 下 命令 : 


$ ./mongod --port 5586 --fork --logpath mo 
forked process: 45082 
all output going to: mongodb.log 

















































































































注意 ，mongod 可 能 在 意识 到 自身 启动 前 ， 便 开始 
预 配置 日 志文 件 。 这 时 ， 直 到 预 配置 完成 ，fork 
命令 才 会 返回 命令 提示 符 。 可 查看 mongodb. ee 
牛 《 或 重 定向 日 志文 件 ) 末尾 ， 观 察 这 一 操作 过 











































































































首次 安装 启动 MongoDB 时 ， 应 查看 一 下 日 志 。 这 
一 点 很 容易 被 忽视 ， 尤 其 是 使 用 初始 化 脚本 来 启 
动 MongoDB 的 时 候 。 但 日 志 中 常 包 含 重 要 的 警告 
言 息 ， 及 时 解决 这 些 问题 可 预防 随 之 而 来 的 错 
误 。 如 启动 时 没有 出 现任 何 警告 ， 那 么 就 一 切 就 
绪 了 。《“ 启 动 时 发 出 的 警告 信息 会 同时 出 现在 
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shell 里 。) 


如 在 启动 时 出 现 了 警告 信息 ， 应 把 它们 记录 下 
来 。MongoDB 会 因 以 下 问题 发 出 警告 : 运行 于 32 
位 的 机 器 上 (MongoDB 并 非 为 32 位 机 器 设计 ); 
启用 了 NUMA (Non-Uniform Memory Access， ». 4 
均匀 访 存 模型 ， 启 用 此 会 严重 拖 慢 应 用 的 运行 速 
E) ; 或 者 系统 所 允许 打开 的 文件 描述 符 
(descriptor) 数目 过 少 (MongoDB 需 使 用 大 量 的 
个 描 述 符 ) 。 


启 数据 库 时 ， 日 志 的 前 部 不 会 发 生 更 改 ， 所 以 
了 解 了 日 志 内 容 ， 就 完全 可 以 使 用 初始 化 脚 
本 来 运行 MongoDB， 而 不 用 去 考虑 日 志 。 然 而 ， 
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xc 





上 由 
iE 






























































0 升级 ， 或 从 朋 恋 中 恢复 后 ， 都 应 重新 检 











启动 数据 库 时 ，MongoDB 会 将 一 个 文档 写 入 
local.startup log 集合 中 ， 该 集合 包含 了 MongoDB 
的 版 本 、 其 所 基于 的 系统 ， 以 及 所 用 的 标记 : 


> db.startup_log.findOne() 
{ 









































"id" : "spock-1360621972547", 
"hostname" : "spock", 

"startTime" : ISODate("2013-@2-11T22:3 
"startTimeLocal" : "Mon Feb 11 17:32:5 





"cmdLine" : { 
}， 

"pid" : 28243, 
"buildinfo" : { 


"version" : "2.4.@-rc1-pre-", 


"“versionArray" : [ 


©, 
-9 
], 


"javascriptEngine" : "V8", 


"bits" : 64, 
"debug" : false, 


"maxBsonObjectSize" : 16777216 


} 

















该 集合 可 用 于 跟踪 数据 库 升 级 或 更 改 后 的 运行 状 

















况 。 











使 用 配置 文件 





























MongoDB 文 持 从 文件 中 读 取 配 置信 息 。 














选项 很 多 ， 或 自动 化 启动 任务 时 ， 使 用 配置 文件 











就 十 分 实用 。 使 用 -f 或 - -config 标 记 ， 











告知 服 





当 使 用 的 





























务 器 使 用 配置 文件 。 例 如 ， 运 行 mongod -- 
config ~/ .mongodb.conf， 从 而 使 
j~/ .mongodb .conf 作 为 配置 文件 。 


配置 文件 中 支持 的 参数 和 在 命令 行 中 的 参数 完全 
相同 。 以 下 是 一 个 配置 文件 的 例子 : 














































































































# Start MongoDB as a daemon on port 5586 


port 5586 

fork = true # daemonize it! 
logpath = /var/log/mongodb. log 
logappend = true 




















该 配置 文件 指定 的 参数 与 之 前 启动 时 在 命令 行 中 
指定 的 参数 相同 。 文 件 中 也 展现 了 MongoDB 配 置 
文件 的 主要 内 容 : 


。 # 后 的 内 容 ， 会 被 作为 注释 忽略 掉 ; 

。 指定 参数 的 语法 是 option = value, 
option 的 名 称 区 分 大 小 写 ; 

。 在 命令 行 中 类 似 - -fork 的 开关 选项 ， 应 # 
fork 的 值 设 为 true 。 
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20.2 停止 MongoDB 





安全 停止 运行 中 的 MongoDB 服 务 器 ， 与 安全 启动 














该 服务 器 一 样 重要 。 有 若干 不 同 选项 可 有 效 地 完 
成 这 一 操作 。 


关闭 运行 中 的 服务 器 ， a. 
perlite duo 村 re ge AL 
个 管理 员 命 令 ， 必 须 运 行 在 admin 数 据 库 
shell 提 供 了 一 个 辅助 函数 ， 用 以 简单 地 执 


行 shutdown 命 令 : 












































id 
ae 












































> use admin 

switched to db admin 

> db.shutdownServer() 
server should be down... 














EETA (primary) 上 运行 shutdown 命 令 时 ， 
服务 器 在 关闭 前 ， 会 先 等 待 备份 节点 
(secondary) 追赶 (catch up〉 主 节点 以 保持 同 
步 。 这 将 回 滚 的 可 能 性 降 至 最 低 ， 但 shutdown 
操作 有 失败 的 可 能 性 。 如 几 秒 钟 内 没有 备份 节点 
成 功 同 步 ， 则 shutdown 操 作 失 败 ， 主 节点 亦 不 
会 停止 运行 : 












































> db.shutdownServer() 

{ 
"closest" : NumberLong(1349465327), 
"difference" : NumberLong(2@), 
"errmsg" : "no secondaries within 10 s 


"ok" : 6 
} 


可 使 用 force 选 项 ， 强 制 关 闭 主 节点 : 


























db.adminCommand({"shutdown" : 1, "force" : 











这 相当 于 发 送 一 个 SIGINT 或 SIGTERM 信 号 (三 
种 做 法 都 能 使 MongoDB 安 全 地 停止 运行 ， 但 可 能 
会 有 数据 未 能 完成 同步 ) 。 如 服务 器 正在 终端 中 
作为 前 台 进 程 运 行 ， 那 么 按 下 Ctrl-C 快 捷 键 也 能 
发 送 一 个 SIGINT 信 号 。 男 外 ，ki11l 之 类 的 命令 也 
可 用 于 发 送 这 些 信和 号。 假设 mongod 的 

PID (Process identifier， 进 程 标识 符 〉 为 10014， 
那么 相应 的 命令 就 是 ki11 -2 10014 (AIK 
SIGINT 信 号) 或 Ki11 10014 (发 送 SIGTERM 信 
oe 



























































mongod 收 到 SIGINT 或 SIGTERM 信 号 后 ， 会 安全 
地 停止 运行 。 这 意味 着 mongod 会 等 当前 正在 进行 
的 操作 或 文件 预 分 配 结束 〈 耗 时 一 定时 间 ) ， 再 
关闭 所 有 打开 的 连接 ， 将 缓存 写 入 磁盘 ， 继 而 结 
束 运行 。 
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20.3 ”安全 性 








不 要 将 MongoDB 服 务 器 直接 暴露 在 外 网 上 。 应 尽 
可 能 地 限制 外 部 对 MongoDB 的 访问 。 最 好 的 方式 

是 设置 防火 墙 ， 只 允许 内 部 网 络 地 址 对 MongoDB 
的 访问 。 第 23 章 介绍 了 MongoDB 服 务 器 与 客户 端 
间 的 必要 连接 。 


除 使 用 防火 墙 外 ， 也 可 在 配置 文件 中 加 入 以 下 选 
项 来 增强 安全 性 。 





































































































e --bind_ip 











指定 MongoDB 监 听 的 接口 。 我 们 通常 将 其 设 
置 为 一 个 内 部 下 地 址 ， 从 而 保证 应 服务 器 
和 集群 中 其 他 成 员 的 访问 ， 同 时 拒绝 外 网 的 
访问 。 如 MongoDB 与 应 用 服务 器 运行 于 同一 
台 机 器 上 ， 则 可 将 其 设 为 localhost。 但 配 
置 服务 器 和 分 片 需要 其 他 机 器 的 访问 ， 所 以 
不 应 设 为 1ocalhost。 




















































































































e --nohttpinterface 


MongoDB 启 动 时 ， 默 认 在 端口 1000 启 动 一 个 
微型 的 HTTP 服 务 器 。 该 服务 器 可 提供 一 些 
系统 信息 ， 但 这 些 信 息 均 可 在 其 他 地 方 找 
到 。 对 于 一 个 可 能 只 需 通过 SSH 访 问 的 机 

器 ， 没 有 必要 将 这 些 信息 暴露 在 外 网 上 。 




































































除了 





正在 进行 乱 








e --nounixsocket 


如 不 打算 使 
叭 用 此 选项 。 























MongoDBiZ 47 在 





用 UN 
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IX socket 来 进行 连 
有 在 本 地 ， 即 应 月 


Ff 发 ， 否 则 请 关闭 此 选项 。 


接 ， 则 可 
有 服务 器 和 




















同一 台 机 器 上 时 














socket 进行 连接 。 


--noscrip 


该 选项 完全 禁止 服务 器 端 JavaScript 脚 本 的 运 


行 。 大 多 数 


JavaScript 有 关 。 如 程序 允许 的 话 ， 


ting 


AAR 











报告 的 MongoDB 安 全 
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JavaScripti 





一 些 shell 中 
JavaScript, 


止 了 JavaScript 的 月 





时 ， 会 出 





不 要 局 




















会 更 安全 一 些 。 
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该 界 





其 是 sh.status()。 在 
R 务 器 上 运行 这 些 辅助 函数 
见 错误 提示 。 


jREST 操 作 界面 。 He BRU SEA 








， 才 能 使 用 





问题 都 与 
禁止 


DR 





数 依赖 于 服务 器 端的 


在 一 台 禁 
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的 ， 开 局 后 可 在 服务 器 上 执行 很 多 命令 ， 但 并 非 

















为 9 


20.3.1 数 


E 产 环境 所 设 








据 加 密 


ER 











截止 至 撰写 本 书 时 ，MongoDB 还 未 提供 内 置 数 据 
加 密 机 制 。 如 需 对 数据 进行 加 密 ， 可 使 用 加 密 文 
件 系统 。 另 一 种 做 法 是 手动 加 密 某 些 字段 ， 但 
MongoDB 无 法 查询 加 密 的 值 。 



























































20.3.2 ”SSL 安 全 连接 





连接 至 MongoDB 传 输 的 数据 默认 不 被 加 密 。 然 
而 ，MongoDB 支 持 使 用 SSL 连 接 。 SP ALO 
忆 ， 默 认 版 本 中 并 未 包含 SSL， 可 从 
http://www.10gen.com 下 载 一 个 支持 SSL 的 版 本 。 
也 可 以 自己 己 编译 MongoDB 的 源 代码 局 用 SSL。 请 
查阅 本 国语 言 的 驱动 程序 文档 ， 了 人 解 创建 SSL 连 
接 的 方法 。 







































































20.4 日 志 


o 日 志 发 送 至 stdout (标准 输出 ， 通 
常 为 终端 ) 。 大 多 初始 化 脚本 会 使 eee 
选项 ， 将 日 志 发 送 至 文件 。 如 在 同一 台 机 器 上 有 
多 个 MongoDB 实 例 〈 比 如 说 一 个 mongod 和 一 
mongos) ， 注 意 保 证 各 实例 的 日 志 分 别 存放 在 单 
独 的 文件 中 。 确 保 知道 日 志 的 存放 位 置 ， 并 拥有 
文件 的 读 访 问 权 限 。 

































































MongoDB 会 输出 大 量 
quiet 选 项 (该 选项 会 隐藏 部 分 日 








持 日 志 
够 的 


H 














言 息 进行 基本 调试 
等 ) ， 但 日 








日 志 消 














息 ， 但 请 








不 要 使 用 -- 








= 

















志 消 息 ) 。 


保 





级 别 为 默认 值 通 常 不 错 ， 此 时 日 六 
(如 耗 时 过 长 








长 或 启 





中 有 足 


ZIJT T 











志 占 


























j 某 特定 


a 
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数目 











用 的 空间 并 
问题 时 ， 可 使 用 一 些 选项 从 








改 。 


不 大 。 














调试 应 
[ 





JÒ 





日 ; 








和 先 ， 在 重启 MongoDB 时 ， 可 通过 在 参数 中 附加 
更 多 的 “w”( 即 -v、-vv、-vvv、-vvvv 或 - 

vvvvv) ， 或 运行 如 下 setParameter 命 令 ， 完 成 
GAH) Coglevel) 的 更 








> db.adminCommand({"setParameter" 


tod, "1o| 








各 日 志 








id 得 将 





级 别 重 设 为 0， 











多 不 必要 的 内 容 。 
二 日 志 


mongod 会 











一 个 请 求 所 处 理 
志文 件 ， 





都 写 入 了 日 对 
操作 do), 














时 看 到 正在 进行 节 








更 好 的 方法 : 


可 将 日 











志 级 别 


+q 


HR 


调 高 至 








否则 





中 记录 几 
的 内 容 。 























乎 所 有 的 操 








于 mongod; 








此 














会 存在 过 





至 5， 这 时 
fe, PLP AE 
各 所 有 内 容 

















可 产生 大 量 











从 而 拖 








忙碌 的 系 








作 ， 打 开 分 


的 磁盘 读 写 
统 。 如 需 即 
析 器 不 失 为 


MongoDB 默 认 记 录 耗 时 超过 100 守 秒 的 查询 信 








息 。 如 100 毫 秒 不 适 























于 应 

















J ， 可 通过 





setProfilingLevel1 命 令 来 更 改 此 闵 值 ; 





// Only log queries that take longer tha 
db.setProfilingLevel(1, 500) 

"was" : @, "slowms" : 100, "ok" : 1 } 
db.setProfilingLevel(@) 

"was" : 1, "slowms" : 500, "ok" : 1 } 


AVA V Vv 




















上 述 第 二 条 指令 将 关闭 分 析 器 ， 但 第 一 条 指令 中 
以 毫秒 为 单位 的 值 将 继续 作为 所 有 数据 库 中 日 志 
记录 的 阔 值 而 生效 。 也 可 使 用 --slowms 选 项 重 
启 MongoDB 来 更 改 这 一 阔 值 。 


最 后 ， 设 置 一 个 计划 任务 以 便 每 天 或 每 周 分 嘎 
(rotate) 日 志文 件 。 如 使 用 --logpath 选 项 启动 
MongoDB， 向 进程 发 送 一 个 SIGUSR1 信 号 即使 其 
对 日 志 进 行 分 制 。 也 可 使 用 logRotate 命 令 以 达 
到 相同 目的 : 






























































=. 



























































> db.adminCommand({"logRotate" : 1}) 

















如 不 是 通过 --logpath 选 项 启动 的 MongoDB， 则 
不 能 对 日 志 进 行 分 割 。 
































第 21 章 ”监控 MongoDB 








在 部 署 前 设置 某 种 监控 系统 很 是 重要 。 监 控 系 统 
应 该 能 够 跟踪 服务 器 正在 运行 的 操作 ， 也 能 够 在 
遇 到 问题 时 及 时 发 出 警报 。 本 章 将 学 习 ; 


。 如 何 跟踪 监测 MongoDB 的 内 存 使 用 状况 ; 
。 如 何 跟踪 监测 应 用 的 性 能 指标 ; 
。 如 何 诊 断 复制 中 的 问题 。 
























































本 章 以 MMS (Mongo Monitoring Service，Mongo 
监控 服务 ) 为 例 ， 演 示 监 控 时 应 注意 的 内 容 。 请 
于 https://mms.10gen.com 查 找 MMS 的 安装 说 明 。 如 
不 想 使 用 MMS， 也 可 使 用 其 他 监控 系统 。 监 控 系 
统 可 在 故障 发 生前 检测 到 潜在 问题 ， 并 有 助 于 我 
们 对 于 问题 的 诊断 。 


21.1 监控 内 存 使 用 状况 


访问 内 存 中 的 数据 很 快 ， 而 访问 磁盘 中 的 数据 则 
较 慢 。 不 幸 的 是 ， 二 者 相 比 ， 内 存 较 为 昂贵 ， 而 
MongoDB 通 常 也 会 优先 使 用 内 存 。 本 节 将 讲述 有 
关 MongoDB 与 内 存 和 磁盘 进行 交互 的 监控 方式 ， 
以 及 监控 中 应 关注 的 内 容 。 













































































21.1.1 有 关 电 脑 内 存 的 介绍 




















电脑 中 一 般 会 有 容量 小 且 访 问 速度 快 的 内 存 ， 以 
及 容量 大 但 访问 速度 慢 的 磁盘 。 当 请 求 一 页 存储 
于 磁盘 上 但 尚未 存 于 内 在 中 的 数据 时 ， 系 统 就 会 
产生 一 个 缺 页 中 断 ， 而 后 将 此 页 数据 从 磁盘 复制 
到 内 存 。 此 后 就 可 以 极 快 地 访问 内 存 中 的 页 面 。 
如 程序 不 再 使 用 此 页 面 内 容 ， 而 内 存 又 被 其 他 页 
所 占 满 ， 旧 的 页 面 就 会 被 清除 出 内 存 而 只 存在 于 



























































































































































将 一 页 数据 从 磁盘 复制 到 内 存 ， 比 从 内 存 中 读 取 
一 页 数据 耗 时 更 长 。 因 此 ，MongoDB 从 磁盘 复制 
数据 的 操作 越 少 越 好 。 如 果 MongoDB 能 够 在 内 存 
中 进行 几乎 所 有 操作 ， 则 访问 数据 的 速度 就 能 快 
很 多 。 所 以 ，MongoDB 的 内 存 使 用 情况 ， 是 要 跟 
踪 监 测 的 最 重要 指标 之 一 。 














































































































21.1.2 跟踪 监测 内 存 使 用 状况 



































MongoDB 所 使 用 的 内 存 有 几 种 不 同 的 类 型 。 第 一 
种 是 常 驻 内 存 (resident memory) : MongoDB 在 
物理 内 存 中 明确 拥有 的 内 存 部 分 。 例 如 ， 在 查询 
文档 时 ， 该 页 面 即 被 载 入 内 存 中 ， 并 成 为 常 驻 内 
存 的 一 部 分 。 





















































MongoDBIiit 
存 中 页 

















予 页 面 一 个 地 址 ， 此 地 纪 
[的 真实 地 址 ， 而 是 一 个 虚拟 地 址 。 








将 











真正 的 4 














二。 











EJ JEME 








ey 

















J 存 中 清 


址 。 这 样 ， 














CIN H Jo 








找 。 但 请 注意 ， 


比 地 址 传 给 内 核 ， 
匆 理 地 
青 除 出 去 ，MongoDB 依 
拟 地 址 来 访问 此 页 
存 ， 内 核 会 在 它 的 页 缓存 (page cache) : 








继而 由 内 核 将 
使 内 核 需 将 


~ 
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CV A 

















可 通 


KASAN 
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MongoDB 癌 内 核 请 求 内 
进行 查 
该 页 并 不 在 此 处 。 查 找 失 败 会 产 





























生 缺 页 中 断 ， 
至 
TH] » 即 构成 了 


























继而 将 此 页 复种 


中 包含 了 MongoDB 访 问 过 的 所 


有 数据 。 


| 至 内 存 ， 最 后 返 
lMongoDB。 这 些 MongoDB 赋 予 了 地 址 上 














口 











的 数据 页 
映射 内 存 (mapped memory) ， 其 























通常 情况 


下 ， 映 射 内 存 的 大 小 约 等 于 整个 数据 集 的 大 小 。 


了 一 个 虚拟 地 址 


， 以 供 日 























同样 





(参见 第 19 章 ) 。 


这 并 不 意 




















MongoDB 所 使 





虚拟 内 存 的 总 








如 关闭 了 日 
拟 内 存 的 大 小 。 











y 
分 配 : 





二 者 与 实际 
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内 存 中 有 着 两 
止 而 已 。 所 以 ， 


i=) 














PEA, BR Ui ET BS 





记 机 制 ， 则 映射 内 存 的 大 小 约 等 于 








时 集 的 两 倍 大 小 。 





MongoDB 为 映射 内 存 中 的 每 个 页 面 ， 都 额外 维护 
W Gournaling) 使 用 

i 味 着 
的 数据 ， 有 的 只 是 两 个 地 二 
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， 约 是 映射 内 存 





tT 








hie 





E 意 ， 虚 拟 内 存 和 映射 内 存 均 不 是 “ 真 
































们 只 是 MongoDB 维 护 


ry 























企 上 ， 


的 内 存 大 小 毫 无 关系 ， 它 
的 映射 里 了 。 理 六 


MongoDB 可 映射 1 PB (petabyte, 1PB=1000 TB=1 
000 000 GB) 的 内 存 ， 但 实际 只 使 用 了 几 GB 的 物 
里 内 存 。 a eee 
小 超过 物理 内 存 的 容 


图 21-1 是 MMS 中 内 存 信 息 的 图 像 ， 描 述 了 
MongoDB 所 使 用 的 常 驻 内 存 、 虚 拟 内 存 和 映射 内 
存 的 大 小 。 在 一 台 专门 用 于 运行 MongoDB 的 机 器 
上 ， 假 设 工 作 集 (working set) 的 大 小 不 小 于 内 
存 容 量 ， 则 常 驻 内 存 的 大 小 应 稍 小 于 总 的 内 存 大 
小 。 只 有 常 驻 内 存 的 大 小 才 确 切 地 等 于 其 在 物理 
内 存 中 所 占用 的 空间 ， 但 这 一 数据 并 不 能 说 明 
MongoDB 所 使 用 的 内 存 大 小 。 
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内 存 + 2 ¢ 28 O 


2013/02/16 20:37: resident:344.97 GB virtual:2,078.41 GB mapped: 1,038.21 GB 
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图 21-1 从 上 至 下 依次 为 虚拟 内 存 、 映 射 内 存 


和 常 驻 内 存 


数据 如 果 能 全 部 存放 
应 与 数据 差不多 大 小 。 











中 ”时 ， 通 常 指 的 是 在 物理 





在 内 存 中 的 
当 说 到 数 




















21.1.3 ”跟踪 监测 缺 页 中 断 


话 ， 则 常 驻 








据 “ 在 内 存 





RAH. 








如 图 21-1 所 示 ， 内 存 的 使 














yy, TI 








而 后 保持 不 变 。 


























会 增长 到 可 





除了 以 每 种 内 存 各 占 
也 数据 得 知 MongoDB 的 内 存 使 用 方式 。 





过 其 














] 多 少 空间 














很 实 | 


的 一 个 指标 是 














量 表明 
这 一 事件 的 发 生 频率 。 
间 内 发 生 缺 页 中 断 的 
发 生 次 数 较 少 ， 但 这 






































为 依据 ， 还 可 通 








发 生 缺 页 中 





























断 的 数量 ，; 


内 存 


状况 通常 比较 稳定 ， 
和 了 映射 内 存 也 得 


用 物理 内 存 的 大 












































次 数 。 图 21- 














问题 。 











如 果 图 21-2 中 的 磁盘 外 






































页 中 断 ， 而 应 用 程序 
的 延迟 ， 那 么 有 这 人 么 


男 一 方面 ， 如 果 应 | 
数据 造成 




















可 以 处 理 这 
多 缺 页 中 断 





EE Ah FE 





3 





























wet Ale 


了 MongoDB 所 寻找 的 数据 不 在 物理 内 存 中 
图 21-2 和 图 21-3 为 一 段 时 
缺 页 中 断 的 
数据 本 身 并 不 能 说 明 很 多 
这 么 多 的 缺 
些 磁盘 操作 造成 



































程序 无 法 处 
的 延迟 ， 则 只 能 将 所 有 数据 存放 到 
































里 从 磁盘 











中 读 取 
内 存 


中 ， 或 者 使 用 固态 硬盘 (solid state drive, 
SSD) 。 
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图 21-2 ”一 个 每 分 钟 发 生 百 余 次 缺 页 中 断 的 系 
统 


缺 页 中 断 


图 21-3 


6.0 


40 


“Thi WG vee Oe 
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一 个 每 分 钟 发 生 几 次 缺 页 中 断 的 系统 








无 论 应 














盘 超 负 
作 数 目 





发 连锁 
界 点 ， 
此 ， 应 


监测 一 
数量 的 





BEF 
值 是 应 


























能 否 处 理 这 些 延 迟 ， 缺 页 中 断 都 会 在 磁 
荷 时 成 为 大 问题 。 人 磁盘 能 够 处 理 的 读 取 操 
并 非 是 线性 的 ， 一 旦 磁盘 开始 超 负荷 运 
行 ， 每 个 操作 都 必须 排队 等 候 更 长 时 间 ， 从 而 引 











反应 。 磁 盘 的 超 负荷 运行 通常 存在 一 个 临 
超出 临界 点 后 磁盘 的 性 能 会 迅速 
避免 磁盘 的 最 大 负荷 运转 。 


段 时 间 内 缺 页 中 断 的 数量 。 如 应 用 
































RR. K 

















在 某 一 




















缺 页 中 断 下 表现 良好 ， 贝 
处 理 的 缺 页 中 断 数 量 底线 。 如 应 用 














> 








j 表 明 其 为 系统 可 
性 能 在 缺 页 中 





至 茶 一 数值 时 开始 发 生 恶化 ， 则 表明 该 数 





发 出 警告 的 临界 值 。 








在 serverStatus 命 令 输出 的 recordStats 字 段 

















中 ， 可 看 到 每 个 数据 库 的 缺 页 中 断 情况 : 











> db.adminCommand({"serverStatus" : 1})["r 


{ 





}), 


Jo 
"bat": { 
"accessesNotInMemory": 199373, 
"pageFaultExceptionsThrown": 6632 
3 
"config": { 
"accessesNotInMemory": @, 
"pageFaultExceptionsThrown": 6 
}, 
"local": { 
"accessesNotInMemory": 2, 
"“pageFaultExceptionsThrown": 6 
} 


"accessesNotInMemory": 200632, 
"test": { 
"accessesNotInMemory": 1, 
"pageFaultExceptionsThrown": 6 
J 
"pageFaultExceptionsThrown": 6633, 
"admin": { 
"accessesNotInMemory": 1247, 
"pageFaultExceptionsThrown": 1 

















其 中 的 accessesNotInMemory 表 示 ，MongoDB 
自 启动 以 来 必须 去 磁盘 上 读 取 数据 的 次 数 。 














21.1.4 减少 索引 树 的 脱 靶 次 数 














访问 不 在 内 存 中 的 索引 条 目 时 效率 尤其 低下 ， 因 
为 这 一 操作 通常 会 造成 两 次 缺 页 中 断 ， 分 别 发 生 
在 将 索引 条 目 和 文档 加 载 入 内 存 之 际 。 查 询 索引 
造成 缺 页 中 断 时 ， 我 们 称 其 为 索引 树 的 脱 著 
(btree miss) 。MongoDB 也 会 监测 索引 树 中 部 
(btree hits) 的 次 数 ， 即 无 需 到 磁盘 上 访问 索 
引 。 图 21-4 中 可 看 到 这 两 个 数值 。 


索引 十 分 常用 ， 通 常 处 于 内 存 中 ， 但 如 果 内 人 存 过 
小 而 索引 又 过 多 ， 或 访问 模式 不 正常 《例如 进行 
大 量 的 表 扫描 ) ， 都 会 造成 索引 树 脱 靶 次 数 的 增 
长 。 通 常情 况 下 ， 脱 靶 次 数 应 保持 在 很 小 的 数 
值 ， 因 此 ， 一 旦 发 现 该 数值 过 高 ， 则 须 着 手 找 出 
问题 的 源头 。 







































































































































































btree + 82 f ooo 





2013/02/14 02:57: accesses:44.1 hits:43.7 misses:0.460 resets:0 
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图 21-4 索引 树 状 况 图 表 


21.1.5 IO 延迟 

IO 延迟 指 CPU 闲 置 等 待 磁盘 响应 的 时 间 。 通 常情 
况 下 ， 该 延迟 与 缺 页 中 断 密切 相关 。 一 些 IO 延 迟 
是 正常 的 ， 因 为 MongoDB 有 时 须 对 磁盘 进行 访 

问 ， 且 无 法 完全 避免 对 其 他 操作 的 妨碍 。 重 要 的 
是 ， 需 保证 IO 延迟 不 再 持续 增长 或 增 至 100% 左 
右 。 如 图 21-5 所 示 ， 这 表明 磁盘 正在 超 负 荷 运 

转 。 
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图 21-$S ”IO 延迟 处 于 100% 左 


右 





MMS 可 通过 安装 插件 munin 来 监测 CPU 信息 。 如 


需 查 看 安装 说 明 ， 请 访问 





https:/mms.10gen.comyhelp/install.html#hardware- 


monitoring-with-munin-node 。 


21.1.6 ”跟踪 监测 后 台 刷 新 平均 时 间 














需 关 注 的 另 一 磁盘 参数 是 ，MongoDB 将 脏 页 
(dirty page) 写 入 磁盘 所 花费 的 时 间 ， 即 后 台 刷 
新 平均 时 间 (background flush average) 。 该 数据 
相当 于 一 个 警钟 。 一 旦 所 需 时 间 开 始 延长 ， 就 表 


























示人 磁盘 的 速度 跟 不 上 需要 处 到 





的 请 求 。 


MongoDB 默 认 会 以 至 少 每 分 钟 一 次 的 频率 ， 将 所 


有 绥 存 中 的 数据 刷 ; 
新 ， 这 取决 于 操作 


来 配置 这 















































的 情况 下 ，MongoDB 可 能 会 


系统 。 


-syncdelay 选 项 后 的 参数 ， 


新 到 磁盘 中 。 
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以 更 高 的 频率 
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进行 
) 可 在 启动 mongod 时 
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以 为 syncdelay 选 项 
但 实际 


上 二 者 毫 无 关系 。 
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青 况 下 ， 我 们 希望 后 台 
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j 于 调节 磁盘 性 


位 ， 


时 间 间 隔 的 值 。 同 步 的 频率 越 高 ， 每 
效率 也 会 随 之 降低 。 


E> DA 











| 新 平均 时 间 能 够 低 
器 上 或 慢 束 磁盘 上， 该 时 间 














时 间 会 变 得 越 来 越 长 
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着 MongoDB 会 不 出 





成 了 更 大 的 负担 ) 。 











Halt 
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[用 时 超过 60 秒 ， 
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i 党 试 进行 刷新 
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是 可 以 接受 的 。 但 
则 是 我 们 不 希望 看 
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磁盘 刷 














H 现 数 十 秒 的 长 时 间 


新 时 间 偶尔 出 现 高 
写 入 


的 运行 ， 所 需 


出 负 


这 意味 








(这 又 对 磁盘 造 


条 





图 21-6 为 后 台 刷 新 平均 时 间 的 曲线 变化 图 。 该 系 
统 的 硬盘 驱动 器 压力 很 大 ， 总 是 需要 大 于 5 秒 的 
时 间 来 写 入 前 一 分 钟 产生 的 数据 。 速 度 有 些 慢 ， 
尤其 是 经 常会 出 现 近 20 秒 时 长 的 高 峰 期 ， 所 以 可 
能 有 必要 将 syncdelay 的 值 调 低 一 些 ， 比 如 说 40 
秒 ， 然 后 看 看 每 次 刷新 较 少 的 数据 是 否 会 有 帮 
助 。 



























































| 后 台 刷 新 平均 时 间 +|elzjele 
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图 21-6 起 负荷 系统 的 后 台 刷 新 平均 时 间 


如 果 后 台 刷 新 平均 时 间 长 时 间 超 出 磁盘 所 能 承受 
的 值 《 可 能 只 超 了 几 秒 钟 ) ， 就 应 该 开始 考虑 如 
何 减 轻 磁盘 的 负载 。 
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据 ) ， 
载 的 大 小 ， 





无 法 表现 
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新 平均 时 











还 应 同时 


\ 需 刷新 脏 数据 ( 即 发 9 
所 以 后 台 刷 
即 写 入 操作 和 写 入 数据 的 数量 。 
此 ， 如 果 写 入 负载 很 低 ， 


间 通 党 


M A à 





甬 常 


新 








更 改 的 数 
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平均 时 间 可 能 











改 盘 的 压力 大 小 。 





























通常 情况 下 ， 
速度 就 越 快 。 
速度 从 快 到 慢 排列 ) 。 
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除 后 
监测 IO 延迟 和 缺 页 中 断 的 情况 。 


计算 工作 集 的 大 小 
存 中 数据 越 多 ，MongoDB 的 运行 


台 刷 新 平均 时 
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。 整个 数据 集 均 在 内 存 中 。 
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所 有 内 
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虽然 
错 ， 但 通常 代价 过 大 或 不 可 行 。 J 
的 响应 速度 足够 快 才能 达成 。 
工作 和 集 处 于 内 存 中 。 这 是 最 常见 的 选择 。 

















J) 。 





时 才 需 访问 磁盘 。 
。 索 引 处 于 内 存 中 。 


。 索引 的 工作 集 处 于 内 存 中 。 


容 ， 但 通常 来 讲 
覆盖 90% 请 求 的 核心 数据 集 〈 如 | 
最 近 一 个 月 的 活 嫩 
里 内 存 中 ，MongoDB 的 运行 速度 
快 ， 因 为 它 只 有 在 遇 到 少数 "不 寻常 "的 请 求 


有 所 使 用 的 数据 和 
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应 用 可 遇 到 如 下 情况 (运行 











这 种 情况 4 
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索引 才能 达成 此 种 情况 〈 详 见 第 5 章 内 


容 ) 。 











。 内存 中 没有 可 | 














的 数据 子 集 。 可 能 的 话 ， 应 




















避免 这 种 情况 。 这 会 使 数据 库 运行 缓慢 。 


我 们 必须 通过 了 入 

















工作 集 的 内 容 及 大 小 来 判断 能 





否 将 其 存 入 内 存 。 


跟踪 分 析 一 些 





数据 有 多 少 。 








例如 ， 





计算 工作 集 大 小 的 最 好 方式 是 
常用 的 操作 ， 从 而 找 出 应 用 的 读 写 



































假设 应 用 每 周 会 创建 2 GB 的 

















新 数据 ， 而 其 中 800 MB 是 经 常 被 访问 的 。 用 户 通 





























常 只 会 访问 近 一 个 月 的 数据 ， 更 早 的 数据 则 通常 

















不 会 被 用 到 。 























这 样 工 作 集 大 小 可 能 是 3.2 





GB (800MB/ 周 x4 周 ) 左右 ， 再 根据 经 验 估计 一 


下 索引 大 小 ， 加 起 来 大 概 是 5 GB。 
则 一 段 时 间 内 被 访问 的 数据 来 考虑 


z JA y 


可 通过 跟踪 监 ; 

















这 一 问题 ， 如 图 21-7 所 示 。 如 选择 尽快 满足 90% 
的 请 求 ， 则 这 一 时 间 段 内 生成 的 数据 和 索引 即 为 


























工作 集 ， 如 图 

















使 用 了 时 间 ， 








21-8 所 示 。 可 测量 这 一 时 间 的 长 
短 ， 从 而 计算 出 数 # 


BEG) 








中 集 的 增长 情况 。 注 意 ， 此 例 
的 新 旧作 为 参数 ， 但 同时 可 





























能 存在 更 适 ) 





于 应 用 











的 访问 模式 (时 间 是 最 常用 





的 一 种 ) 。 


被 访问 次 数 


数据 新 旧 程 度 





图 21-7 数据 新 旧 程 度 与 被 访问 次 数 的 关系 





被 访问 次 数 


TFE 


数据 新 旧 程 度 








图 21-8: 工作 集 即 经 常 进行 的 请 求 所 访问 的 数 
据 


还 可 通过 MongoDB 的 状态 来 估计 工作 集 的 大 小 。 
MongoDB 保 留 有 一 个 记录 内 存 内 容 的 图 表 ， 可 
将 "workingSet"” : 1 参数 传 入 serverStatus 
来 得 知 这 些 内 容 : 


> db.adminCommand({"serverStatus" : 1, "wo 


{ 







































































“workingSet" : { 
"note" : "thisIsAnEstimate", 
"pagesInMemory" : 18, 
"computationTimeMicros" : 3685, 
"overSeconds" : 2363 


}s 











pagesInMemory 指 MongoDB 认 为 当前 内 存 中 的 页 
面 数目 。 实 际 上 ，MongoDB 并 不 知道 其 确切 数 
值 ， 但 结果 应 该 很 接近 。 在 返回 信息 中 ， 如 果 内 
存 中 的 页 面 数目 与 内 存 大 小 相等 ， 则 该 数值 没有 
什么 价值 ， 但 如 果 页 面 数 目 小 于 内 存 大 小 ， 则 该 
数值 可 能 与 工作 集 的 大 小 有 关 。 
















































































































































































默认 不 包 


Of 
ya 


serverStatus Jik E 
含 workingSset 字 段 。 





一 些 工作 集 的 例子 





假设 工作 集 大 小 为 40 GB。90% 的 请 求 能 够 命中 
工作 集 ， 其 他 10% 则 需 访 问 工 作 集 以 外 的 数据 。 
如 果 有 500 GB 的 数据 和 50 GB 的 内 存 ， 则 工作 集 
可 全 部 放 入 内 存 中 。 一 旦 应 用 访问 了 需 经 常 访问 
的 数据 ( 即 预 热 过 程 》， 则 无 需 在 访问 工作 集 时 
再 次 访问 磁盘 。 有 10 GB 的 空间 提供 给 460 GB 不 
常 访问 的 数据 。 显 然 ，MongoDB 几 平 总 是 要 到 磁 
盘 上 访问 工作 集 以 外 的 数据 。 


另 一 方面 ， 假 设 工作 集 无 法 放 入 内 存 。 比 如 只 有 
35 GB 的 内 存 。 这 种 情况 下 工作 和 集 通常 会 占据 大 
部 分 的 内 存 。 工 作 集 中 的 内 容 经 常 被 访问 ， 因 而 
更 有 可 能 留 在 内 存 中 ， 但 有 时 不 常 访问 的 数据 也 
会 被 载 入 内 存 ， 从 而 将 工作 集 (或 其 他 不 常 访问 
的 数据 ) 挤 出 内 存 。 于 是 ， 内 存 和 磁盘 会 频繁 进 
行 数 据 交 换 ， 此 时 无 法 再 预测 访问 工作 集中 数据 
的 性 能 


21.3 ”跟踪 监测 性 能 状况 






































































































































































































































































































































几 种 方式 可 | 
请 求 负荷 。 





MongoDB 占用 CPU 时 ， 大 商 
的 读 写 上 (IO 延迟 很 高 ，3 
而 ， 如 果 用 户 或 者 系统 

(或 者 100% 乘 
JAN 


























一 个 党 














查询 的 性 能 通常 应 重点 监测 并 使 3 
] 来 监测 MongoDB 是 否 能 承受 当前 的 


HJU 











其 保持 稳定 。 有 





分 时 间 花 在 了 处 理 器 














ri} 














其 他 指标 可 忽略 ) 。 然 
的 CPU 时 间接 近 100% 








以 CPU 的 数量 ) ， 最 可 外 
鼎 少 合适 的 索引 。 另 一 种 可 能 性 
是 运行 了 太 多 的 MapRedues 或 其 
JavaScript 脚 本 。 
所 有 碍 询 的 表 3 
了 一 个 新 版 本 的 应 | 

















有 必要 跟踪 监测 CPU， 








见 与 预想 中 的 相符 ， 特 另 











j 之 后 。 














他 的 服务 器 端 


的 原因 是 








从 而 确保 
上 是 在 部 署 

















注意 ， 图 21-9: 










































































9 数量 较 低 ，IO 延 迟 可 能 被 其 他 CPU 活动 所 拖 
只 有 在 其 他 活动 增长 时 ， 缺 少 合适 的 索引 才 


o 





cpu 时 间 + 2/2 o | 





2013/02/16 06:22: user:6.54 nice:0 system:3.29 lowaillt:0.1 irq:4.44e-3 softirg:0.34 steal:0 
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图 21-9 ”一 个 有 着 最 小 IO 延迟 的 CPU 状态 图 。 
上 面 的 曲线 表示 用 户 的 CPU 时 间 ， 下 面 的 是 系 
统 的 CPU 时 间 。 其 他 数据 都 非常 接近 0% 


y= 个 相似 的 指标 是 队列 长 度 ， 即 有 多 少 请 求 正 
在 等 待 MongoBD 的 处 理 。 请 求 在 等 待 锁 进行 读 写 
操作 时 ， 即 被 认为 是 处 于 队列 中 。 图 21-10 为 读 写 
队列 随时 间 变 化 的 图 像 。 不 存在 队列 为 最 佳 ( 此 
时 图 像 基 本 为 空白 ) ， 但 无 需 针对 这 一 指标 发 出 
警报 。 在 一 个 繁忙 的 系统 中 ， 操 作 需 耗 时 等 待 以 
获取 所 需 的 锁 ， 这 一 点 很 常见 。 
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图 21-10 ” 读 写 队列 随时 间 变 化 的 图 像 


可 通过 队列 中 的 请 求 数量 ， 判 断 是 否 发 生 了 阻 
塞 。 通 常 队列 的 长 度 应 该 很 低 。 一 个 很 长 且 始 终 
存在 的 队列 表示 mongod 无 法 承受 其 负载 。 应 尽快 
减轻 该 服务 器 的 负荷 。 


可 将 队列 长 度 和 锁 比 例 Clock percentage) 两 个 指 
标 结 合 起 来 ， 锁 比例 指 MongoDB 处 于 锁定 中 的 时 
间 。 一 般 来 讲 ， 相 较 于 发 生 锁 定 ， 人 磁盘 IO 更 倾向 
于 限制 写 入 。 但 依然 有 必要 对 锁定 进行 跟踪 监 
测 ， 尤 其 是 磁盘 速度 快 ， 或 连续 写 入 多 的 系统 。 
重复 一 遍 ， 锁 比例 过 高 的 最 普遍 原因 之 一 就 是 缺 
少 了 合适 的 索引 。 随 着 锁 比 例 的 增加 ， 操 作 取 得 
锁 所 需 的 平均 等 待 时 间 越 来 越 长 。 因 此 ， 过 高 的 
















































































锁 比 例会 将 所 有 东西 拖 慢 ， 导 致 请 求 堆积 ， 以 及 
系统 中 更 高 的 负荷 和 更 高 的 锁 比 例 。 图 21-11 中 显 
示 了 极 高 的 锁 比 例 ， 这 种 情况 应 尽快 得 到 处 理 。 


随 着 流量 大 小 的 变化 ， 锁 比例 常会 发 生起 伏 变 

化 。 但 如 果 锁 比例 长 时 间 保 持 上 升 趋势 ， 则 表明 
系统 所 受 的 压力 较 大 ， 应 做 一 些 调整 。 因 此 ， 应 
在 锁 比 例 长 时 间 保 持 过 高 的 值 后 再 触发 警报 〈 这 
样 当 流 量 突然 增加 时 就 不 会 触发 警报 了 ) 。 


另 一 方面 ， 我 们 可 能 也 希望 在 锁 比 例 突 然 升 高 
时 ， 比 如 说 高 于 正常 值 23% 时 触发 警报 。 该 数值 
可 能 表明 系统 无 法 承载 突然 升 高 的 负荷 ， 也 许 应 
该 提高 系统 的 性 能 和 容量 了 。 
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， MongoDB 
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下 几 个 选项 。 
就 增加 一 个 分 片 。 
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| 成 员 。 








了 directoryperdb 选 项 ， 


使 新 成 员 追 





。 对 集合 中 的 每 个 

















数据 库 








Tv 
应 用 











增长 速度 非常 快 ， 可 将 数据 库 移 至 其 驱动 器 
内 。 挂 载 驱 动 器 为 数据 目录 。 这 样 就 可 不 必 








移动 其 他 数据 内 容 了 。 


























从 采取 哪 种 方法 ， 请 提前 做 好 准备 ， 从 而 使 对 





产生 的 影响 降 至 最 低 。 








请 先 做 好 备份 ， 依 次 


修改 副本 集中 的 每 个 成 员 ， 并 将 数据 从 一 处 复制 


BA 


21.4 


一 处 。 
监控 副本 集 





对 副本 集中 的 落后 Cag) 和 oplog (operation 




















log) 


落后 。 





个 备 


3:26:00 p.m.， 主 节点 刚刚 完成 














长 度 进行 跟踪 监测 十 分 重要 。 
当 备份 节点 无 法 与 主 节点 保持 一 致 时 ， 就 产生 了 








份 节点 刚刚 完成 了 一 次 操 





主 节点 最 后 一 次 操作 的 时 间 和 备份 节点 最 
后 一 次 操作 的 时 间 差 值 ， 即 落后 的 值 。 例 如 ， 一 
































间 惟 为 3:29:45 p.m.， 此 时 落后 的 值 即 为 3 分 45 


秒 。 














落后 的 值 越 接近 0 越 好 ， 





Wit NER 














别 。 如 果 一 个 备份 节点 能 够 与 主 节 点 保持 同步 ， 





0。 




















副本 集落 后 的 值 应 如 图 21-12 所 示 ， 基 本 保持 为 


16:00 17:00 18:00 19:00 20:00 21:00 





图 21-12 一 个 不 存在 落后 的 副本 集 ， 这 是 最 理 
想 的 状态 


如 果 备 份 节点 的 复制 速度 赶不上 主 节 点 的 写 入 速 
度 ， 就 会 开始 出 现 非 0 的 落后 值 。 最 极端 的 情况 
是 副本 集 发 生 了 阻塞 : 由 于 某 种 原因 ， 副 本 集 无 
法 再 接受 任何 操作 。 这 种 情况 下 ， 每 经 过 一 秒 ， 
落后 的 值 就 会 增加 一 秒 ， 在 图 像 中 呈现 一 个 陡坡 
的 样子 ， 如 图 21-13 所 示 。 这 可 能 是 由 于 网 络 问 题 
引起 的 ， 也 可 能 是 由 于 缺少 了 _id 索 引 ， 副 本 集 
要 求 每 个 集合 都 拥有 这 一 索引 才能 正常 工作 。 


如 果 集 合 缺 少 了 _id 索 引 ， 将 服务 器 脱离 副本 集 
作为 一 个 独立 服务 器 启动 ， 然 后 建立 _id 索 引 。 
确保 建立 的 _id 索 引 是 唯一 索引 (unique 

























































































































































































index) 。 索 引 建立 完成 后 ， 除 非 删 除 整个 集合 ， 
否则 _id 索 引 不 能 发 生 删 除 或 更 改 。 
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图 21-13 阻塞 ， 并 于 2 月 10 日 前 开 





始 进行 恢复 。 色 线 条 表示 服务 器 的 重新 启动 


a eM 点 可 能 会 逐渐 被 主 节 
点 落下 。 但 图 中 通 不 会 显示 出 特 4 下 明显 的 “每 
秒 增加 一 秒 ” 的 B E, 因为 备份 节点 还 是 进行 了 
一 些 复制 的 。 然 而 ， 备 份 节点 到 底 是 因为 无 法 与 
高 峰 流 量 保 持 一 致 而 被 落下 的 ， 还 是 逐渐 被 主 节 
点 落下 的 ， 这 一 点 十 分 重要 。 




































































主 节点 不 会 为 了 “帮助 ”备份 节点 追赶 上 来 而 限 各 
写 入 ， 所 以 在 超 负 荷 运行 的 系统 上 备份 节点 追赶 





= 




















不 上 的 情况 时 有 发 生 ( 尤 其 是 MongoDB 中 写 入 的 
优先 级 比 读 取 要 高 ， 这 意味 着 副本 集 的 性 能 很 大 
程度 上 取决 于 主 节点 ) 。 可 在 写 入 时 使 用 “w”* 参 
数 来 强制 限制 主 节点 的 写 入 。 lee oe 
至 其 他 节点 ， 从 而 降低 备份 节点 的 负载 。 


而 在 一 个 负载 极 低 的 系统 上 ， 可 在 副本 集落 后 值 
的 图 像 中 看 到 另 一 种 有 趣 的 图 案 ， 即 突然 出 现 的 
高 峰值 ， 如 图 21-14 所 示 。 这 些 峰 值 表示 的 并 不 是 
真正 的 落后 ， 而 是 由 抽样 的 变化 产生 的 。mongod 
每 隔 几 分 钟 处 理 一 个 写 入 操作 。 落 后 的 值 是 主 节 
点 和 备份 节点 的 时 间 惟 差 值 ， 而 对 备份 节点 时 间 
戳 的 测量 恰好 发 生 在 主 节 点 的 写 入 操作 之 前 ， 这 
使 得 备份 节点 看 起 来 好 像 落 后 了 几 分 钟 一 样 。 如 
果 增 加 写 入 频率 ， 这 些 峰值 就 会 消失 。 
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图 21-14 ” 写 入 操作 数量 较 少 的 系统 会 产生 “ 伪 落 后 ” 


另 一 需要 跟踪 监测 的 重要 指标 是 每 个 节点 的 oplog 
长 度 。 每 个 可 能 成 为 主 节 点 的 节点 都 应 拥有 一 份 
长 度 超过 一 天 的 oplog。 如 一 个 节点 可 能 成 为 另 一 
个 节点 的 同步 源 (sync source) ， 则 应 拥有 一 份 
长 度 足 够 进行 初始 化 同步 (initial syne) 的 
oplog。 图 21-15 为 标准 的 oplog 长 度 图 像 。 该 oplog 
长 度 极 佳 ， 达 1111 小 时 ， 即 超过 一 个 月 的 数据 ! 
通常 ， 在 保证 磁盘 空间 充足 的 前 提 下 ，oplog 应 尽 
可 能 地 长 。oplog 几 乎 不 占用 内 存 。 而 且 长 oplog 
的 缺乏 ， 可 能 会 带 来 痛苦 的 回忆 。 































































































| 复制 o + A+ a0 
1111.11h 


555.56h 





13:00 14:00 15:00 16:00 17:00 18:00 























图 21-15 ”典型 的 oplog 长 度 图 像 





图 21-16 为 较 短 的 oplog 和 变化 的 流量 引起 的 稍 显 
不 同 寻 常 的 变化 。 运 行 仍旧 正常 ， 但 该 机 器 上 的 
oplog 可 能 太 短 了 〈6 到 11 小 时 的 维护 时 段 ) 。 管 
E 员 有 机 会 的 话 应 将 该 oplog 的 长 度 加 以 延长 。 
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次 流量 高 峰 的 应 用 oplog 长 

















图 21-16 每 天 有 
度 








第 22 章 ”备份 











对 系统 进行 定期 备份 是 很 重要 的 。 对 于 大 多 故障 
而 言 ， 备 份 是 很 好 的 保护 措施 ， 只 有 很 少 的 故障 
无 法 通过 恢复 干净 的 备份 得 到 解决 。 本 章 我 们 将 












































学 习 下 列 有 关 备 份 的 常用 选项 : 


。 单一 服务 器 的 备份 ; 
。 对 副本 集 进行 备份 时 的 特别 考虑 ; 
。 如 何 对 一 个 分 片 集群 进行 备份 。 












































只 有 在 有 信心 能 在 紧急 情况 下 完成 迅速 音 
况 下 ， 备 份 才 是 有 | 





























bp 署 的 情 








月 


的 。 所 以 ， 无 论 选 择 了 哪 种 


备份 技术 ， 一 定 要 对 备份 及 恢复 备份 的 操作 进行 








练习 ， 直 到 了 然 于 心 。 
22.1 对 服务 器 进行 备份 


























备份 有 许多 种 方法 。 但 无 论 采 用 哪 种 方法 ， 备 份 














操作 都 会 增加 系统 的 负担 :备份 通常 需 将 所 有 数 
据 读 取 到 内 存 中 。 因 此 ， 通 常情 况 下 ， 应 对 副本 
















































































空闲 时 段 对 独立 服务 器 进行 备份 。 


集 的 非 主 节点 (与 主 节 点 相对 〉 进 行 备份 ， 


或 在 











如 非特 殊 声 明 ， 本 节 中 的 所 有 技术 均 适 | 











mongod 程 序 ， 无 论 是 独立 服务 器 还 是 副本 集成 





j 于 任何 


Wo 


22.1.1 文件 系统 快照 





生成 文件 系统 快照 Csnapshot) 是 最 简单 的 备份 
方法 。 然 而 ， 该 方法 的 实现 需要 两 点 条 件 ， 即 文 
牛 系统 本 身 支 持 快照 技术 ， 以 及 在 运行 mongod 时 
必须 开启 日 记 系 统 (journaling) 。 如 系统 满足 这 
两 点 条 件 ， 则 该 方法 无 需 其 他 准备 ， 只 需 生 成 快 
照 即 可 ， 时 间 不 限 。 


在 恢复 时 ， 确 保 mongod 没 有 在 运行 。 从 快照 恢复 
数据 的 确切 命令 取决 于 不 同 的 文件 系统 ， 不 过 基 
本 上 就 是 恢复 快照 ， 然 后 启动 mongod 即 可 。 如 果 
是 对 正在 运行 的 系统 生成 快照 ， 那 么 快照 中 的 数 
据 内 容 本 质 上 相当 于 使 用 kil1 -9 命令 强制 终止 
mongod 后 的 数据 内 容 。 因 此 ，mongod 在 启动 时 会 
对 日 志 (journal) 文件 进行 重 放 (replay) ， 然 后 
开始 正常 运行 。 












































































































































22.1.2 ”复制 数据 文件 














另 一 种 备份 方式 是 复制 数据 目录 中 的 所 有 文件 。 
没有 文件 系统 的 文 持 ， 我 们 就 无 法 同时 复制 所 有 
文件 ， 因 此 在 进行 备份 时 必须 防止 数据 文件 发 生 


















































改变 。 可 使 用 fsynclock 命 令 做 到 这 一 








> db.fsyncLock() 








ZA 命令 锁定 (lock) 数据 库 ， 禁止 任何 写 入 ， 并 
进行 同上 Cfsync) ， 即 将 所 有 脏 页 刷新 至 磁盘 ， 
以 确保 数据 目录 中 的 文件 是 最 新 的 ， 且 不 会 被 更 


















































= 
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旦 运行 了 这 一 命令 ，mongod 会 将 之 后 的 所 有 写 
操作 加 入 队列 等 待 ， 且 在 解锁 前 不 会 对 这 些 写 
操作 进行 处 理 。 注 意 ， 这 一 命令 会 停止 所 有 数 
库 的 写 入 操作 ， 而 不 只 是 已 连接 的 那个 数据 

































































作证 





当 fsynclock 命 令 返 回 命令 行 后 ， 复 制 数 据 目录 
中 的 所 有 文件 到 备份 位 置 。 在 Linux 中 ， 可 使 用 以 









































$ cp -R /data/db/* /mnt/external-drive/bac 




















确保 复制 了 数据 目录 中 的 每 一 个 文件 和 文件 夹 到 
备份 位 置 。 漏 掉 文 件 或 文件 夹 可 能 会 损坏 备份 或 
使 其 不 再 可 用 。 


数据 复制 完成 后 ， 解 锁 数 据 库 ， 使 其 能 够 再 次 进 































































































行 写 入 操作 : 


> db.fsyncUnlock() 



































数据 库 即 开始 正常 处 理 写 入 操作 。 


注意 ， 身 份 验证 和 fsynclock 命 令 存 在 一 些 锁定 
问题 。 如 果 启 用 了 身份 验证 ， 则 在 调 
jfsyncLock() 和 fsyncUnlock() 期 间 不 要 关 
六 shell。 如 果 在 这 期 间断 开 了 连接 ， 则 可 能 无 法 
进行 重新 连接 ， 并 不 得 不 重启 
mongod。fsyncLock() 的 设 定 在 重启 后 不 会 保持 
生效 ，mongod 总 是 以 非 锁 定 模式 启动 。 


除 使 用 fsynclock 外 ， 还 可 关闭 mongod， 复 制 文 
牛 ， 然 后 重启 mongod。 关 闭 mongod 会 将 所 有 更 改 
立即 刷新 到 磁盘 ， 防 止 备份 期 间 出 现 新 的 写 入 操 







































































































































































若 要 恢复 数据 目录 备份 ， 请 保证 mongod 没 有 在 运 
行 ， 且 所 有 待 恢复 的 数据 目录 为 空 。 将 备份 的 数 
据 文 件 复制 到 数据 目录 ， 然 后 启动 mongod。 例 

下 列 命令 会 使 用 前 面 提 及 的 命令 恢复 备份 文 


$ cp -R /mnt/external-drive/backup/* /data 
$ mongod -f mongod. conf 

















































































































忽略 那些 有 关 复 制 部 分 数据 目录 的 警告 信息 。 只 
要 知道 要 复制 哪些 文件 ， 即 可 使 用 这 种 方式 备份 
单独 的 数据 库 。 例 如 ， 要 备份 名 为 myDB 的 数据 
库 ， 只 需 复 制 所 有 名 为 myDB.* 的 文件 ， 包 括 后 绥 
名 为 ,ns 的 文件 。 如 使 用 了 - -directoryperdb 选 
项 ， 只 需 复制 该 数据 库 对 应 的 整个 数据 目录 。 


可 复制 数据 库 对 应 的 文件 到 数据 目录 ， 完 成 指定 
数据 库 的 恢复 。 如 需 进 行 这 种 部 分 恢复 ， 应 确保 
数据 库 上 一 次 是 正常 关闭 的 。 如 遇 到 骨 省 或 突然 
停机 ， 不 要 艾 试 恢复 一 个 单独 的 数据 库 ， 而 应 用 
备份 文件 替换 整个 数据 目录 ， 然 后 启动 mongod， 
从 而 允许 日 记 文 件 进行 重 放 。 



































































































































































































































“不 要 同时 使 用 fsyncLock 和 
mongodump 。 数 据 库 被 锁定 也 许 会 使 得 
mongodump 永 远 处 于 挂 起 状态 ， 这 取 诀 于 数据 库 
正在 进行 的 其 他 操作 。 



































22.1.3 ”使 用 mongodump 


最 后 一 种 备份 广 


























份 和 恢复 的 速度 较 慢 ， 在 
问题 〈 参 见 22.2 节 
当 想 备份 单独 尼 
时 mongodump 是 











运行 mongodump --help， 可 看 到 mongodump 具 
门 重点 关注 那些 与 备份 相关 








方式 是 使 用 mongodump。 之 所 以 最 
为 mongodump 有 些许 缺点 。 它 备 

















处 理 副本 集 时 存在 一 些 





















































个 很 好 的 选择 。 


有 很 多 选项 。 此 处 我 











的 实用 选项 。 
要 备份 所 有 数据 库 
































集合 其 至 集合 中 的 子 身 
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如 果 在 同一 台 机 器 
只 需 指 定 mongod 运 行 时 




















只 需 运 行 nongodump 即 可 。 
上 运行 mongod 和 mongodump， 





占用 的 端口 即 可 ; 








$ mongodump -p 31000 





mongodump 会 在 当前 目 


























录 中 的 目录 和 


























使 用 mongodump 时 其 























|MongoDB É 














录 建 立 一 个 转 储 dump) 
目录 ， 其 中 包含 了 一 份 所 有 数据 的 倾 卸 。 转 储 
录 由 数据 库 和 集合 构成 。 真 正 
的 数据 存放 在 扩展 名 为 .bson 的 文件 里 ， 其 中 以 
BSON 格 式 依次 存储 了 集合 中 的 所 有 文档 。 可 使 
带 的 bsondump 工 具 查 看 .bson 文 件 。 



















































































至 无 需 服务 器 处 于 运行 状 











态 : 可 使 用 - -dbpath 选 项 来 指定 数据 目录 ， 
































mongodump 会 使 用 指定 的 数据 文件 进行 备份 。 








$ mongodump --dbpath /data/db 



































如 果 mongod 正 在 运行 ， 则 不 应 使 用 - -dbpathiz 
项 。 











mongodump 存 在 一 个 问题 ， 即 它 并 非 进行 快照 备 
份 ， 也 就 是 说 在 备份 的 过 程 中 ， 系 统 可 能 会 继续 
进行 号 入 操作 。 于 是 可 能 出 现 ， 开 始 备份 时 
mongodump 先 对 数据 库 A 进 行 转 储 ， 随 后 在 
mongodump 正 在 对 数据 库 B 进 行 转 储 的 同时 ， 删 
除了 数据 库 A。 然而 mongodump 
行 了 转 储 ， 于 是 最 终 转 储 得 到 的 结果 ， 是 一 个 在 
原 服务 器 上 并 不 存在 的 数据 快照 。 


为 避免 这 种 情况 的 发 生 ， 如 果 运 行 mongod 时 使 用 
了 --replSet 选 项 ， 则 可 使 用 mongodump 的 -- 
oplog 选 项 。 这 会 将 转 储 过 程 中 服务 器 进行 的 所 
有 操作 记录 下 来 ， 这 样 在 恢复 备份 时 就 会 重新 执 
TÈ FE。 这 样 就 可 以 得 到 源 服务 器 上 某 一 时 
间 点 的 数据 快照 。 


如 果 给 mongodump 一 个 副本 集 的 连接 字 串 〈 例 
如 ，setName/seed1， Seed2, seed3) ; a 
份 节点 存在 的 话 ， 它 会 自动 选择 一 个 备份 节点 进 










































































































































































行 转 储 




















工具 





o 





恢复 mongodump 产 生 的 备份 ， 可 使 用 mongorestore 








$ mongorestore -p 31666 --oplogReplay dump 


























如 果 转 储 数据 库 时 使 用 了 --oplog 参 数 ， 运 行 


Imongorestore 时 

















以 得 到 茶 一 时 间 点 的 快照 。 




















如 果 在 运行 的 服务 器 上 进行 数 
drop 选 项 ， 以 在 恢复 一 个 集合 前 先 删除 它 。 当 然 
此 选项 并 非 必 选 项 。 


随 着 版 本 的 变 








必须 使 用 --oplogReplay 选 项 ， 





导 蔡 换 ， 可 使 用 -- 












































的 具体 作用 和 用 法 发 生 了 改变 。 

















题 ， 应 尽量 使 用 同 版 本 的 mongodump 和 




















化 ，mongodump 和 mongorestore 命 令 


为 避免 兼容 性 问 


mongorestore。 可 运行 mongodump --version 和 


mongorestore --version 来 查看 各 自 的 版 本 。 


1. 使 




















和 数据 库 


可 从 转 














| mongodump 和 `mongorestore 来 转移 集合 








诸 中 恢复 完全 不 同 的 数 


























FEMRE. XE 


不 同 环境 中 使 用 不 同 的 数据 库 名 称 〈 例 如 ，dev 
































和 prod) ， 但 集合 的 名 称 相 同时 ， 这 一 特性 会 很 
实用 。 


将 一 个 扩展 名 为 .bson 的 文件 恢复 为 特定 的 数据 库 
和 集合 ， 只 需 在 命令 行 中 指定 恢复 目标 : 




















$ mongorestore --db newDb --collection som 























1. 管理 唯一 索引 带 来 的 混乱 


在 任何 集合 中 ， 如 果 存 在 除 _id 以 外 的 其 他 唯一 
索引 〈unique index) ， 则 应 考虑 使 用 mongodump 
和 mongorestore 以 外 的 备份 方式 。 L 体 地 说 ， 唯 一 
索引 要 求 复制 期 间 数据 不 发 生 可 能 破坏 其 唯一 索 
引 约束 的 改变 。 最 安全 的 方法 是 先 想 办 法 “ 冻 
结 ” 数 据 ， 然 后 使 用 前 两 节 中 提 到 的 方法 来 进行 
备份 。 













































































































































































如 果 决 定 使 用 mongodump 和 mongorestore 进 行 备 
份 ， 那 么 在 恢复 备份 时 ， 可 能 需要 对 数据 进行 一 
定 的 预 处 理 。 


22.2 ”对 副本 集 进 行 备份 


通常， 应 该 对 备份 节点 进行 备份 :这 会 为 主 节 点 
减轻 负担 ， 也 可 以 在 不 影响 应 用 的 情况 下 锁定 备 




































































种 ， 对 副本 集中 的 成 员 进 行 备份 ， 但 推荐 使 用 文 
件 系 统 快照 或 复制 数据 文件 的 方式 。 这 两 种 方式 
在 应 用 于 副本 集 备 份 节点 时 无 需 做 任何 修改 。 


副本 和 集 启用 后 ， 使 用 mongodump 进 行 备份 就 不 那 
么 简 音 了。 首先， 如果 使 用 mongodump， 则 必须 
在 备份 时 使 用 - -op1og 选 项 ， 来 得 到 一 个 基于 某 
时 间 点 的 快照 ;否则 备份 的 状态 不 会 和 任何 其 他 
集群 成 员 的 状态 相 吻 合 。 在 恢复 时 也 必须 创建 一 
份 oplog， 否 则 被 恢复 的 成 员 就 不 知道 应 该 同步 到 
那里 。 




































































































































































要 从 mongodump 生 成 的 备份 中 ， 对 副本 集成 员 进 
行 恢复 ， 可 将 该 成 员 作为 一 个 单独 的 服务 器 局 
动 ， 此 时 要 使 用 一 个 空 的 数据 目录 。 首 先 ， 像 上 
一 节 中 提 到 过 的 那样 ， 使 用 --oplogReplay 选 项 
运行 mongorestore。 现 在 它 应 该 包含 了 一 份 完 整 的 
数据 副本 ， 但 还 需要 一 份 oplog。 运 

行 createCollection 命 令 来 建立 oplog;: 



















































































> use local 
> db.createCollection("oplog.rs", {"capped 











以 字 节 为 单位 指定 集合 大 小 。 可 参见 12.4.6 节 ， 








了 解 更 多 与 此 相关 的 内 容 。 


Ea 
见 在 需要 填充 oplog。 最 简单 的 方式 是 用 备份 中 的 
oplog.bson 文 件 来 填充 local.oplog.rs 集 合 : 






































$ mongorestore -d local -c oplog.rs dumpyo| 














注意 ， 这 并 不 是 对 于 oplog 的 转 储 文件 

(dump/local/oplog.rs.bson) ， 而 是 进行 转 储 期 间 
发 生 的 操作 。 一 旦 mongorestore 完 成 ， 即 可 将 服务 
器 作为 副本 集成 员 重 新 启动 。 


22.3 ”对 分 片 集群 进行 备份 


“可 能 对 正在 运行 的 分 片 集群 进行 “完美 地 ” 备 

份 ， 因为 无 法 及 时 得 到 集群 在 某 一 时 间 点 完整 状 
态 的 快照 。 然 而 ， 通 常情 况 下 都 会 避 开 该 限制 ， 
忆 为 随 着 集群 的 增 大 ， 从 备份 中 恢复 整个 集群 的 
可 能 性 越 来 越 小 。 因 此 ， 在 面 对 分 片 集群 时 ， 我 
门 更 关注 分 块 的 备份 ， 即 单独 备份 配置 服务 器 和 













































































































































































在 对 分 片 集群 进行 备份 和 恢复 操作 之 前 ， 应 先 关 
闭 平 衡器 。 这 是 因为 在 过 于 混乱 的 环境 中 是 无 法 
得 到 一 份 前 后 一 致 的 快照 的 。 有 关 平 衡器 开启 与 
关闭 的 操作 说 明 ， 请 参见 16.4 节 。 




















22.3.1 备份 和 恢复 整个 集群 














当 集群 很 小 或 正如 


储 和 恢复 整个 集群 。 








平衡 器 ， 然 后 通过 mongos 运 行 
在 mongodump 所 运行 
份 。 








TE 


要 恢复 此 种 备份 ， 


个 mongos。 


关闭 平衡 器 后 ， 
目录 的 方式 ， 























FE 进行 开发 时 ， 
要 达到 这 一 

















IAT 


需 运 





可 使 用 


备份 配置 服务 器 和 每 








文件 






































我 们 可 能 想 要 转 








的 ， 应 先 关 闭 











系统 快照 或 复 第 


mongodump。 这 会 
的 机 器 上 建立 所 有 分 片 的 备 





mongorestore 并 连接 到 一 





| 数据 
片 。 然 





个 分 








而 不 可 避免 






































22.3.2 备份 和 恢复 单独 的 分 片 


只 Æ 


更 多 时 候 ， 





从而 从 


果 不 是 很 挑剔 的 话 ， 


的 是 ， 我 
得 到 这 些 备份 ， 这 可 能 
会 进行 数据 合并 ， 
此 消失 。 








门 不 可 能 在 
造成 问题 。 














恢复 集群 中 的 某 个 


完全 相同 的 时 刻 





另外 ， 在 打开 





在 分 片 中 备份 的 茶 些 








单独 分 片 。 如 























可 使 用 刚 























单独 服务 器 处 型 


E 方 法 进行 分 片 的 备份 











刚 在 前 面 提 到 过 


的 
N 恢复 。 














有 一 个 问 是 
行 了 备份 。 








LEA 
到 了 星 


重 





HER 





: BREA 


时 























期 一 对 集群 进 


























其 四 ， 磁 盘 发 生 损坏 ， 我 们 不 








动 到 了 这 一 分 片上 。 





分 中 并 不 包含 这 些 新 增 的 数据 块 。 也 许 我 们 能 够 
使 用 配置 服务 器 的 备份 ， 找 到 这 些 消 失 了 的 数据 






































得 不 恢复 备份 。 然 而 ， 在 这 几 天 里 ， 新 的 数据 块 
移 


而 周一 进行 的 分 片 备 



































块 在 星期 一 时 的 位 置 ， 但 这 比 只 是 恢复 分 片 要 困 























难得 多 。 在 大 多 数 情况 下 ， 















































通过 mongos。 








恢复 分 片 ， 忽 略 那 些 


消失 的 数据 块 ， 是 更 好 的 选择 。 
可 直接 连接 到 一 个 分 片上 来 恢复 备份 ， 而 不 需要 








22.4 使 用 mongooplog 进 行 增 量 备份 








比 ， 只 发 生 了 很 小 的 更 改 ， 





以 上 提 及 的 备份 方式 ， 即 使 和 上 一 次 备份 时 相 











也 都 必须 对 所 有 数据 






































进行 一 次 完整 的 复制 。 如 果 数 据 和 写 入 量 有 很 大 








的 关系 ， 那 么 我 们 可 能 希望 了 解 一 下 增 量 备份 。 











与 每 天 或 每 周 进行 一 次 完整 的 数据 复 币 
门 只 需 进行 一 次 备份 ， 然 后 使 用 oplog 来 备份 这 之 











I 不 同 ， 我 











后 的 所 有 操作 。 这 种 技术 比 之 前 提 及 的 技术 都 要 




















复杂 ， 因 此 除非 确实 需要 ， 
技术 。 














否则 应 尽量 选择 其 他 





这 一 技术 需要 两 台 运行 mongod 的 机 器 ， 即 机 器 A 

















和 机 器 B。A 是 主机 器 (可 能 





是 副本 集中 的 备份 节 


点 ) ，B 则 用 来 进行 备份 : 


1. 记录 下 A 的 oplog 中 最 近 一 次 的 操作 时 间 
Coptime) : 




















> op = db.oplog.rs.find().sort({$natur 
> start = op['ts']['t']/10e0 

















把 该 数值 记录 在 安全 的 地 方 一 一 等 下 会 用 到 
Be 























2. 对 数据 进行 备份 ， 使 用 以 上 提 及 的 任何 一 种 
方式 ， 得 到 一 份 基于 某 时 间 点 的 备份 。 恢 复 
备份 至 B 上 的 数据 目录 。 


3. 定期 添加 A 上 的 操作 至 B， 从 而 完成 数据 的 复 
制 。MongoDB 的 发 行 版 中 自 带 了 一 个 特殊 的 
工具 mongooplog《〈 读 作 mon-goop-log) ， 将 
这 一 操作 变 得 简单 。mongooplog 从 一 台 服 务 
器 的 oplog 中 复制 数据 ， 并 将 其 中 的 操作 应 用 
在 另 一 台 服 务 器 的 数据 集 上 。 在 B 上 运行 : 


$ mongooplog --from A --seconds 123456 


















































































































































其 中 --seconds 选 项 后 跟 的 参数 ， 应 为 第 一 
步 中 计算 出 的 start 变 量 和 当前 时 间 的 差 
值 ， 再 额外 加 上 几 秒 (重复 地 重 放 操 作 也 好 






































wad 



























































ERR) 。 

这 使 得 备份 更 接近 最 新 的 数据 。 这 种 技术 有 
些 像 是 手动 地 同步 一 个 备份 节点 ， 所 以 我 们 
也 许 只 是 想 在 备份 节点 上 使 用 延 时 复制 以 代 
增 量 备份 。 








第 23 章 A MongoDB 


本 章 将 会 就 部 署 生产 服务 器 给 出 相关 建议 。 具 体 
来 讲 ， 包 括 以 下 几 方 面 : 


。 选 购 硬件 、 挑 选 设置 方法 ; 

。 使 用 虚拟 化 环境 ; 

。 重 要 的 内 核 与 磁盘 IO 设 定 ; 

。 网络 设置 ， 哪些 组 件 之 间 需 要 建立 连接 。 


23.1 设计 系统 结 梳 


通常 ， 我 们 会 希望 对 系统 进行 优化 ， 以 保证 数据 
安全 和 存 取 速度 。 本 节 将 探讨 在 选择 磁盘 、 
RAID 〈 和 磁盘 阵列 ) 配置 、CPU 等 硬件 以 及 基本 软 
件 组 件 的 过 程 中 ， 达 成 以 上 目标 的 最 佳 方法 。 

































































































































































23.1.1 选择 存储 介质 




















如 果 只 考虑 性 能 ， 可 按照 以 下 顺序 选择 介质 ， 从 
而 进行 数据 存 取 











。 固态 人 磁盘; 
。 机械 磁盘 。 








可 惜 ， 大 多 情况 下 ， 由 于 预算 有 限 或 数据 过 多 ， 

天 法 将 所 有 数据 在 入 内 存 ， 而 固态 万 又 过 于 吕 
对 此 ， 标 准 的 部 署 方 案 是 使 用 较 少 的 内 存 空 
间 (具体 大 小 取决 于 总 数据 大 小 和 较 大 的 机 械 
磁盘 空间 。 这 种 情况 下 需 注 意 ， 工 作 集 大 小 应 小 
于 内 存 容 量 ， 同 时 应 做 好 在 工作 集 增 长 时 进行 设 
备 扩展 的 准备 。 


如 果 没 有 经 费 限 制 ， 那 就 去 购买 更 多 的 内 存 或 回 
SRi o 


从 内 存 中 读 取 数据 需 几 纳 秒 的 时 间 《〈 比 如 100 纳 
秒 ) 。 相 反 地 ， 从 磁盘 中 读 取 数据 需 几 毫秒 的 时 
间 (比如 10 毫 秒 ) 。 单 看 这 两 个 数字 很 难 想像 出 
二 者 间 的 差距 ， 但 如 果 我 们 将 它们 按 比 例 放大 就 
会 明白 : 如 果 访 问 内存 耗 时 1 秒 钟 ， 则 访问 磁盘 
需 耗 时 超过 1 天 的 时 间 ! 


100 纳 秒 x10 000 000=1 秒 














































































































































































































10 毫 秒 x10 000 000=1.16 天 


这 些 只 是 近似 的 计算 (磁盘 可 能 略 快 或 内 存 略 
E ， 但 差距 的 大 小 不 会 有 太 大 差别 。 所 以 我 们 
尽量 少 地 访问 磁盘 。 

















即使 是 更 快 的 机 械 磁 盘 ， 也 不 会 使 磁盘 读 取 时 间 
缩短 太 多 ， 所 以 没有 必要 花 太 多 钱 在 这 种 磁盘 
上 。 更 多 的 内 存 或 固态 磁盘 效果 会 更 好 。 


一 个 示例 


图 23-1 至 图 23-6 展 示 了 固态 磁盘 的 优势 。 这 些 图 
片 中 显示 的 ， 是 一 个 在 8 月 8 日 中 午 上 线 的 新 分 片 
的 情况 。 开 始 时 仅 在 机 械 磁 盘 上 部 署 了 一 个 分 

片 ， 随 后 又 在 固态 磁盘 上 部 署 了 一 个 新 的 分 片 ， 
接 下 来 两 个 分 片 同时 运行 。 


如 图 23-1 所 示 ， 机 械 磁 盘 的 性 能 峰值 可 接近 每 秘 
5000 次 查询 ， 但 一 般 情 况 下 只 能 做 到 每 秒 几 百 次 
查询 。 
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操作 计数 A LR PH 

















one 


图 23-1 ”在 机 械 磁盘 上 进行 查询 的 情况 


作为 对 照 ， 图 23-2 中 的 图 表 显 示 了 在 固态 磁盘 上 
进行 查询 的 状况 。 固 态 磁盘 的 性 能 可 保持 每 秒 处 
里 5000 次 请 求 ， 峰 值 则 可 达到 每 秒 30000 次 ! 这 
一 新 的 分 片 完全 可 以 独立 承担 整个 集群 的 工作 。 
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操作 计数 +|2\4 2 © 





12:00 18:00 09Aug 06:00 12:00 














图 23-2 ”在 固态 磁盘 上 进行 查询 的 情况 


有 关机 械 磁 盘 和 固态 磁盘 的 对 比 中 ， 另 一 点 值得 
主意 的 是 频繁 的 磁盘 访问 对 系统 的 压力 大 小 。 在 
使 用 机 械 磁盘 的 服务 器 上 ， 我 们 可 从 其 硬件 监控 
信息 (图 23-3) 中 看 到 ， 磁 盘 工 作 十 分 繁忙 。 图 
中 位 于 上 部 的 曲线 表示 IO 延迟 ， 即 CPU 等 待 磁 盘 
IO 的 时 间 所 占 总 时 间 的 百分比 。 可 以 看 到 该 百 分 
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比 至 少 为 10%， 高 峰 时 常 达 到 $0% 以 上 。 这 意味 
着 磁盘 成 为 了 限制 性 能 的 短 板 〈 所 以 此 人 新 添 了 
固态 磁盘 ) 。 


cpu 时 间 bake 





08Aug 09Aug 


图 23-3 ”查询 期 间 的 CPU 使 用 情况 





























作为 对 比 ， 图 23-4 显 示 了 使 用 固态 磁盘 的 机 器 上 
CPU 的 使 用 情况 。 图 中 甚至 已 经 看 不 出 IO 延迟 的 
痕迹 ， 上 下 两 条 明显 的 曲线 分 别 表 示 系 统 时 间 

(system time) 和 用 户 时 间 Cuser time) 。 因 此 ， 
限制 这 一 机 器 性 能 的 短 板 就 是 CPU 的 运行 速度 。 

图 中 曲线 超过 了 100%， 这 也 说 明 系 统 利用 了 多 个 
处 理 器 核心 。 将 其 与 图 23-3 进 行 对 比 可 发 现 ， 之 
前 的 机 器 由 于 磁盘 IO 速度 过 慢 ， 导 致 得 到 充分 利 
用 的 处 理 器 核心 甚至 还 不 足 一 个 。 
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图 23-4 查询 期 间 的 CPU 使 用 情况 


最 后 ， 在 有 关 锁 时 间 的 图 23-5 中 可 以 看 到 其 对 
MongoDB 的 影响 。 在 机 械 磁 盘 上 ， 数 据 库 10% 到 
25% 的 时 间 处 在 锁 状 态 ， 有 时 峰值 甚至 会 达到 
100%. 
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图 23-$ ”查询 期 间 MongoDB 的 锁 比 例 


与 图 23-6 中 使 用 固态 磁盘 机 器 上 的 锁 比 例 进行 比 
较 。MongoDB 基 本 上 一 直 保 持 非 锁定 状态 。〔 曲 
线 开 始 部 分 的 凸 起 是 在 加 上 固态 磁盘 之 前 的 数据 
读 取 操作 造成 的 。) 




















锁 比 例 + 2 ¢ 2 e 














图 23-6 ”使 用 固态 磁盘 机 器 上 的 锁 比 例 


可 以 看 到 ， 固 态 磁 盘 可 以 承担 比 机 械 磁 盘 多 得 多 
的 工作 ， 但 不 季 的 是 ， 它 们 无 法 被 大 量 部 署 。 如 
果 能 够 使 用 它们 ， 那 就 用 吧 。 就 算 不 可 能 在 整个 
集群 中 使 用 固态 磁盘 ， 也 应 考虑 尽量 多 得 部 署 ， 
然后 使 用 在 第 15 章 中 提 到 的 强制 热点 数据 模型 进 
行 优 化 。 






















































































注意 ， 通 常 我 
磁盘 《如 
固态 磁盘 



























































门 不 外 
副本 集中 存在 





E 向 己 有 的 副本 集中 添加 固态 
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则 其 他 成 员 

















mber ) ’ 并 接管 处 E 














儿 械 磁盘 的 话 ) 。 

的 机 器 成 为 主 成 员 〈primary 
它 所 能 处 理 的 一 切 工作 ， 
， 无 法 及 时 复 和 

















而 被 落 在 后 面 。 








因此 ， MRES 




















的 方法 。 





注意 
异 ， 但 实际 J 
Gournal) 。 























也 不 会 影响 性 








23.1.2 














话 ， 向 集群 中 增 放 


固态 磁盘 对 于 处 理 
上 机 械 磁 盘 完 全 可 以 上 
用 机 械 磁 盘 来 记录 
人 磁盘 记录 数据 ， 这 样 既 能 节省 匡 


E 荐 的 RAID 配 置 















































如 果 使 





数据， 从 


入 固态 磁盘 的 








0 一 个 新 的 分 片 不 失 为 一 种 更 好 





普通 数据 而 言 表 现 优 






















































































J 于 记录 Ak T 


态 磁盘 的 空间 ， 











而 用 固态 








RAID (Redundant Array of Independent Disk， 独 立 








磁盘 元 余 阵 列 


Inexpensive Disk, 














> |IH#kRedundant Array of 
廉价 磁盘 元 余 阵 列 


) 是 一 种 可 





以 让 我 们 把 多 块 磁盘 当 作 单独 一 块 磁盘 来 使 用 的 

















技术 。 可 使 用 
AIA. 
RAID 人 磁盘 阵列 。 

















本 组 使 上 


它 来 提高 磁盘 的 可 靠 性 





或 性 和 能 ’ 或 
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技术 的 磁盘 被 称 作 







































































涂 的 不 同 ， 存 在 着 多 种 配置 方式 ， 通 
# 错 性 。 下 列 是 几 种 最 常见 的 配 


























磁盘 分 割 技术 (disk striping) 将 多 个 磁 


盘 并 列 起 来 以 提升 性 能 。 每 块 磁盘 保存 一 部 
分 数据 ， 与 MongoDB 中 的 分 片 类 似 。 由 于 存 














在 多 个 底层 磁盘 ， 因 此 大 
间 写 入 磁盘 内 。 这 一 方式 可 


丢失 ， 则 这 些 数 据 不 会 存在 备份 。 这 也 会 导 
其 是 在 Amazon 的 Elastic 
RSE) ， 因 为 一 些 数据 卷 可 能 








致 读 取 速度 变 慢 〈 尤 ] 


Block Store} 
比 另 一 些 要 | 








ee 





数据 可 在 同一 时 
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使 用 镜像 来 

















慢 的 成 员 会 





























阵列 中 的 其 


e RAIDS 








在 使 用 磁盘 分 割 技术 的 基 而 


yea ya. 
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被 写 入 到 阵列 的 每 一 个 成 员 当 中 。 这 一 方法 
的 性 能 要 比 RAID0 低 ， 因 为 阵列 中 一 个 速度 
拖 慢 整个 阵列 的 写 入 速度 。 然 
而 ， 如 果 其 中 一 块 磁 盘 发 生 
也 成 员 上 找到 数据 副本 。 
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样 的 数据 副本 会 











故障 ， 还 可 以 在 








上 ， 额 外 存储 数 
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RAID10 


RAID10 是 一 种 RAID0 和 RAID1 的 组 合 : žr 
被 分 割 以 提升 速度 ， 又 被 复制 镜像 以 提高 可 
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能 问题 
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计算 校 验 信息 。 
4 的 多 次 少量 的 数 所 
月 RAID5S 所 带 来 的 代价 





EE 
上 故障 时 
并 不 会 感觉 到 
， 这 也 使 得 RAID5 成 为 这 
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为 它 需要 
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再 使 ) 























23.1.3 CPU 


IRAIDL ATES} 
个 人 喜好 问题 : PEGE T H 


RAIDS, 


























在 副本 集 的 基 








它 非 常 非常 慢 。 





比 RAID0 更 安全 ， 也 能 解决 








础 J 


良 费 ， 从 而 选择 RAID0。 这 是 
FE 能 承担 多 大 的 风险 


MongoDB 对 于 CPU 的 负载 很 轻 ( 注 意 在 图 23-3 和 


图 23-41 
000 次 查询 ) 。 
硬件 投资 ， 























: 两 个 CPU 的 处 理 角 

















如 需 在 内 存 和 ( 
一 定 要 选择 内 存 。 











行 


大 ， 但 直 
法 对 这 两 种 操作 起 到 优化 作用 。 


如 需 在 
比 更 多 





EREA 
算 资 源 ， 但 
索引 和 








E 力 即 可 满足 每 秒 10 
oa an 个 进行 
里 论 上 来 讲 ， 在 进 



































竺 内 存 中 进行 排序 时 

















进行 MapReduce (一 个 | 
并 行 运算 的 软件 架构 ) 运算 时 ， 
直到 本 书写 作 之 时 ， 























在 实践 中 这 种 情况 很 少 发 生 。 


， 会 耗 尽 多 核 的 运 
在 建立 
于 大 规模 数据 集 

对 CPU 的 负载 很 
[处 理 器 核 数 仍 无 
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速度 和 核 数 间 做 出 选 
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23.1.4 选择 操作 系统 


的 并 行 运算 ，MongoDB 能 遇 
的 更 多 周期 进行 运算 。 


择 ， 应 选择 前 者 。 相 























更 好 地 利 
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64 位 Linux 操 作 系 统 是 运行 MongoDB 的 最 好 选择 。 








K| 











Linux 也 很 常用 ) 。 
为 老 昌 的 、 存 在 缺陷 上 











可 能 的 话 应 选择 它 作 为 内 核 系统 。CentOS 和 
RedHat 企 业 版 可 能 是 最 普遍 的 选择 ，] 
版 也 应 能 够 运行 MongoDB (Ubuntu 和 Amazon 





其 他 的 发 行 




















应 使 














生 问 题 。 
64 位 Windows 系 统 也 能 很 好 地 运行 MongoDB。 


最 六 
的 软件 包 或 内 核 有 时 会 产 


所 发 布 的 稳定 版 本 ， 











MongoDB 对 于 其 他 版 本 Unix 系 统 的 文 持 并 没有 那 
么 好 : 如 果 使 用 Solaris 或 者 基于 BSD 的 系统 ， 那 





























么 应 该 小 心 ， 因 为 这 些 




















LR pan, HJMongoDB, #6 


FE (BD MAGE) 很 多 问题 








关于 跨 平台 兼容 ， 有 一 

















点 需 特别 注意 : MongoDB 


在 所 有 系统 中 使 用 同样 的 线路 协议 (wire 
protocol) ， 对 于 数据 文件 中 的 内 容 也 使 用 同样 的 
格式 进行 存储 ， 所 以 我 们 可 以 基于 不 同系 统 的 组 

















a a D 例 如 P 系统 上 












































为 其 分 pe 也 可 在 Windows 和 Timx 间 复制 数据 文 






































牛 ， 而 不 必 考 虑 跨 平台 兼容 的 问题 。 








如 服务 器 需 处 理 大 量 数据 ， 则 不 要 使 用 32 位 系 























统 ， 因 为 这 会 限制 我 们 最 多 只 能 处 理 2 GB 的 数据 
(这 是 由 于 MongoDB 使 用 内 存 映射 的 文件 ) 。 副 












































本 集 的 仲裁 器 和 mongos 进 程 可 以 运行 在 32 位 机 器 





上 。 不 要 在 32 位 机 器 














服务 。 





























运行 其 他 类 型 的 MongoDB 





MongoDB 只 支持 小 端 (litle-endian， 即 存储 二 进 




















制 内 容 时 ， 数 字 的 低位 组 置 于 最 前 











M) 系统 结 























构 。 大 部 分 驱动 都 支持 小 端 和 大 端 Cbig-endian ) 
两 种 系统 结构 ， 因 此 客户 端 在 两 种 系统 中 均 可 运 
行 。 然 而 ， 服 务 器 只 能 运行 在 小 端 结构 的 机 器 

















Je 


23.1.5 ”交换 空间 





应 分 配 一 小 块 交换 空间 ， 以 防 系统 内 存 使 用 过 
多 ， 从 而 导致 内 核 终 止 MongoDB 的 运行 。 然 而 ， 
MongoDB 通 党 并 不 会 使 用 任何 交换 空间 。 


MongoDB 所 使 用 的 大 部 分 内 存 都 是 “不 稳定 的 ”: 
只 要 系统 因 某 些 原因 而 请 求 内 存 空 间 ， 这 部 分 内 
存 中 的 内 容 就 会 被 刷新 到 磁盘 中 ， 然 后 原 内 存 则 
被 蔡 换 成 其 他 内 容 。 因 此 ， 数 据 库 数据 绝 不 应 该 
被 写 入 交换 空间 ， 因 为 它 首 先 会 被 刷新 回 磁盘 。 


然而 ，MongoDB 在 需要 对 数据 进行 排序 ， 即 建立 
索引 或 进行 排序 操作 时 ， 会 使 用 交换 空间 。 在 进 
行 此 类 操作 时 ，MongoDB 会 尽量 不 去 使 用 过 多 内 
但 
交 








































































































































































































存 ， 但 如 果 同 时 进行 很 多 这 种 操作 ， 最 终 就 会 使 
到 交换 空间 。 


如 果 应 用 程序 在 服务 器 上 用 到 了 交换 空间 ， 则 应 
想 办 法 重新 设计 应 用 程序 ， 或 者 减少 那 台 服务 器 
上 的 负载 。 








































































































23.1.6 ”文件 系统 














在 Linux 系 统 上 ， 推 荐 使 用 ext4 或 XFS 文 件 系 统 作 
为 数据 卷 。 具 有 一 个 能 够 在 备份 时 进行 文件 系统 
快照 filesystem snapshot) 的 文件 系统 是 不 错 
的 ， 但 是 会 影响 到 性 能 。 


不 推荐 使 用 ext3 文 件 系统 ， 因 为 它 在 对 数据 文件 
进行 预 分 配 时 耗 时 过 长 。MongoDB 会 定期 分 配 
2GB 大 小 的 数据 文件 并 将 其 内 容 填充 为 0， 在 ext3 
文件 系统 上 ， 这 一 操作 会 造成 几 分 钟 的 卡 顿 。 如 
果 一 定 要 使 用 ext3 文 件 系 统 ， 有 几 个 相关 的 优化 
措施 可 供 选 择 。 不 过 如 果 可 以 的 话 ， 还 是 应 尽量 
使 用 其 他 文件 系统 。 


在 Windows 系 统 上 ， 使 用 NTFS 和 FAT 文 件 系 统 都 
是 可 以 的 。 


= 不 要 直接 使 用 被 挂 载 的 NFS 文 件 系 


统 作 为 MongoDB 的 存储 区 域 。 有 些 版 本 的 客户 
端 会 隐瞒 数据 刷新 的 真实 情况 ， 随 机 重新 挂 载 
和 有 刷新 页 面 缓存 (page cache) ， 且 不 支持 排他 
文件 锁定 Cexclusive file lock) 。 使 用 NFS 文 件 
系统 会 造成 日 志 (Gouna) ARMA, AEM 
尽量 避免 使 用 。 

























































































































































































































































































23.2 ”虚拟 化 


运用 虚拟 化 (virtualization) 技术 可 方便 地 使 用 廉 
价 的 硬件 来 部 署 系统 ， 并 且 能 够 迅速 做 出 扩展 。 
然而 ， 虚 拟 化 也 存在 缺点 ， 尤 其 是 无 法 预知 的 网 
络 和 磁盘 IO 状况 。 本 节 将 探讨 有 关 虚 拟 化 的 具体 


问题 。 



















































































23.2.1 禁止 内 存 过 度 分 配 








内 存 过 度 分 配 (memory overcommitting) 的 设置 
值 决定 了 当 进 程 向 操作 系统 请 求 过 多 内 存 时 应 采 
取 的 策略 。 基 于 这 一 设置 ， 内 核 可 能 会 为 进程 分 
配 内 存 ， 哪 怕 那 些 内 存 当前 是 不 可 用 的 《期 望 的 
结果 是 ， 当 进程 用 到 这 段 内 存 时 它 已 变 为 可 用 
的 ) 。 这 种 内 核 向 进程 许诺 不 存在 的 内 存 的 行 
为 ， 就 叫做 内 存 过 度 分 配 。 这 一 特性 使 得 
MongoDB 无 法 很 好 地 运作 。 






































mw Cu 






















































































vm.overcommit_memory 的 值 可 能 为 0( 让 内 核 
来 猜测 过 度 分 配 的 大 小 ) ， 可 能 为 1 (满足 所 有 
ARFI 分 配 请 求 ) ， 也 可 能 为 2〈 分 配 的 虚拟 地 址 

空间 最 多 不 超过 交换 空间 与 一 小 部 分 过 度 分 配 的 
Al) 。 将 此 值 设 为 2 所 代表 的 意义 最 为 复杂 ， 同 
时 也 是 最 佳 选择 。 运 行 以 下 命令 将 此 值 设 为 2: 


















































|$ echo 2 > /proc/sys/vm/overcommit_memory 























更 改 这 一 设置 后 无 需 重启 MongoDB。 





23.2.2 ”神秘 的 内 存 





有 时 虚拟 层 无 法 正确 地 配备 内 存 。 因 此 ， 一 台 虚 

















拟 机 号 称 拥有 
其 中 的 60 GB. 















































100 GB 可 用 内 存 ， 但 可 能 只 能 使 用 
相反 ， 我 们 曾经 发 现 应 该 只 能 使 
































全 部 存 入 内 存 ! 














120 GB 内 存 的 用 户 ， 却 可 以 将 100 GB 的 数据 集 























BOK A Sie th 
而 虚拟 机 就 是 
机 即 可 。 














CATIA o 如 果 预 读 大 小 设置 合理 ， 
































法 使 用 全 部 内 存 ， 这 时 切换 虚拟 











23.2.3 ”处 理 网 络 磁 盘 的 IO 问题 











PIS A EF EP BORE 


题 之 一 。 我 们 通 


TRAMP REO, KICSIT EEN 
性 外 负担 。 也 正 因 为 此 ， 虚 拟 磁盘 的 性 能 无 法 预 






















































































知 : 当 其 他 使 























其 性 能 就 会 迅 ; 
































j 者 并 不 频繁 使 用 磁盘 时 ， 磁 盘 可 




















以 工作 地 很 好 ， 而 一 旦 其 他 人 开始 压榨 磁盘 时 ， 











速 下 降 。 


另 一 个 问题 是 
器 间 和 常常 并 不 存在 
仅 供 自 己 使 用 ， 
可 能 (虽然 可 

数据 间 失 去 了 网 络 连接 。 
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依然 会 













































































Amazon 拥 有 可 能 是 最 常 
EBS (Elastic Block Store, 

的 卷 可 连接 到 EC2 (Elastic 
云 计 算 ) 实例 ， 并 立即 为 














弹性 块 
1 器 提供 


j 的 网 格 存储 服务 
存储 ) 。 





Compute 





， 存 储 设 备 时 与 MongoDB 运 行 的 机 
上 的 连接 ， 所 以 即使 磁盘 
比 本 地 磁盘 速度 慢 。 这 也 
能 性 不 大 ) 导致 MongoDB 服 务 器 与 





， 称 》 
EBS 中 
Cloud， 弹 性 
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的 磁盘 空间 。 从 积 pan 

















得 非常 简单 〈 在 备份 节 
驱动 到 另 一 个 实例 上 
面 ， 性 能 的 起 伏 会 


如 希望 提高 性 外 
要 保证 系统 性 外 
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点 ] 
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MRE, IEE Ze 
HERE, +EaXEBS 
上 EF， 启动 mongod) 。 
E 常 明显 。 


的 可 预测 性 
其 望 中 的 一 样 











但 为 一 方 





， 有 以 下 儿 个 选项 。 
， 最 直接 的 做 法 











FE 
的 月 
慢 。 
次 于 前 
IOPS 
的 实例 。 可 访问 
新 的 推荐 托管 服务 。 


这 些 选项 都 无 法 实现 ， 








一 种 选 : 















































如 果 


不 要 将 MongoDB 托 管 在 云端 。 
R 务 器 上 可 以 保证 性 能 不 会 被 
不 过 ， 许 多 人 不 会 选择 这 种 做 法 。 
项 的 就 是 选择 能 够 保证 
(IO Operations Per Second， 每 秒 IO 操 作 ) 
http://docs.mongodb.org, AAF 
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托管 在 自己 








其 人 


而 一 














也 使 用 者 拖 
于 是 ， 仅 


三 


E? 里 




















个 高 负载 的 EBS 

















卷 所 提供 
些 手 段 。 


基本 
卷 。 








， 我 们 能 做 的 前 
一 旦 某 个 卷 的 速度 变 




















ie 


的 磁盘 IO 又 无 法 满足 需求 ， 那 么 可 以 使 





视 MongoDB 所 使 用 的 
慢 ， 立 即 终止 这 一 实例 








的 运行 ， 接 着 启动 
例 。 
可 对 以 下 数据 进行 监视 。 
。IO 利 用 率 的 峰值 
原因 显而易见 。 
缺失 (page faults ) 
t, 应 用 程序 本 身 的 
的 变化 : 在 部 署 新 
禁用 这 一 不 断 结束 
e。TCP 丢 包 数 的 增长 情 
这 一 点 尤其 严重 : 当 
繁 发 生 TCP 技 包 的 情 
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或 nongo stat 























个 使 


青 况 (在 Amazon 的 服务 J 








] 另 一 数据 卷 的 新 实 





(MMS 中 的 “IO 延 迟 ”) ， 





RH 
行为 变化 也 
版 本 的 应 月 
并 切换 实 


频率 的 峰值 。 注 
会 造成 工作 
程序 前 ， 应 
网 的 脚本 。 



































性 能 开始 下 降 时 ， 会 频 


HAL) o 
MongoDB 读 写 队列 的 峰值 (该 数据 可 在 MMS 
的 qr/qw 列 串 


变化 ， 








PERED 
应 确保 脚本 考虑 了 计 








生 周 期 性 
EH 


于 执行 计划 任务 
实例 的 运行 。 





























征 工作 格外 繁忙 的 星期 一 


造成 的 影响 而 终止 所 有 














在 使 用 这 些 手 段 之 前 ， 应 保证 对 数据 留 有 备份 ， 
或 存在 可 与 其 进行 同步 的 数据 集 。 如 果 让 每 个 实 
例 都 保存 上 TB 的 数据 ， 我 们 可 能 会 希望 寻找 替代 
方法 。 另 外 ， 该 方法 不 一 定 有 效 ， 如 果 新 分 卷 上 
的 负荷 也 很 大 ， 则 会 和 原来 一 样 慢 。 






















































































23.2.4 ”使 用 非 网 络 磁盘 








本 节 中 使 用 了 一 些 Amazon 服 务 中 特有 的 词汇 。 然 
而 ， 它 也 可 能 适用 于 其 他 提供 J o 


MIKSAS (ephemeral drive) 是 真正 和 虚拟 机 
CVM) 所 在 的 机 器 间 存 在 物理 连接 的 磁盘 ， 所 
以 并 不 存在 很 多 网 络 存 储 中 出 现 的 问题 。 本 地 磁 
盘 依然 可 能 由 于 同一 个 盒子 (box) 中 其 他 用 户 
的 使 用 而 超过 负载 ， 但 通过 使 用 更 大 的 盒子 可 基 
本 确保 不 会 与 特别 多 的 用 户 共 享 磁盘 。 即 使 是 一 
个 稍 小 的 实例 ， 只 要 其 他 使 用 者 没有 造成 大 量 的 
IOPS， 临 时 驱动 器 就 能 经 常 提 供 比 网 络 驱动 器 更 
好 的 性 能 。 


它 的 缺点 从 名 字 上 就 可 以 看 出 来 : 这 些 磁盘 是 临 
时 的 。 如 果 EC2 实 例 停 止 运 行 ， 则 无 法 保证 重新 
启动 实例 后 还 能 在 同一 个 盒子 里 ， 数 据 也 随 之 不 
见 了 。 




























































































































































































































































































此 ， 应 小 心 使 用 临时 驱动 器 。 应 确保 不 要 将 任 
可 重要 的 ， 或 者 没有 备份 的 数据 存放 到 这 些 磁 盘 
里 。 i a 
有 ， 或 是 网 络 男 一 端的 数据 库 里 。 通 常 来 讲 ， 应 
将 临时 驱动 器 当 作 一 个 速度 稍 慢 的 缓存 来 使 用 ， 
而 非 一 块 速度 快 的 磁盘 。 


23.3 ”系统 配置 


以 下 几 个 系统 设置 可 使 MongoDB 的 运行 更 加 稳 
定 ， 且 主要 与 磁盘 和 内 存 的 访问 有 关 。 本 节 将 具 
体 学 习 这 些 选项 及 其 调整 方法 。 
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23.3.1 2 H NUMA 


当 机 器 中 只 有 一 个 CPU 时 ， 所 有 内 存 的 存 取 时 间 
Caccess time) 基本 相同 。 当 机 器 中 开始 有 更 多 
的 处 理 器 时 ， 工 程 师 们 发 现 ， 与 其 将 所 有 内 存 与 
CPU 的 距离 保持 相同 〈 如 图 23-7 所 示 ) ， 不 如 为 
每 个 CPU 都 设置 一 些 距 其 更 近 、 访 问 速度 更 快 的 
内 存 ， 这 样 做 的 效率 会 更 高 。 










































































图 23-7 一 致 内 存 结构 : 每 个 CPU 访问 所 有 内 
存 的 代价 相同 


这 种 每 个 CPU 都 具有 自己 “本 地 ”内 存 的 结构 ， 叫 
做 NUMA (Non-uniform Memory Architecture, 4F 
一 致 内 存 结构 ) ， 如 图 23-8 所 示 。 




















存 ， 不 过 代价 会 


图 23-8 ” 非 一 致 内 存 结构 : 每 个 CPU 连接 一 部 
分 特定 内 存 ， 访 问 这 些 


内 存 时 ， 该 CPU 速度 更 








快 。 问 


更 高 














其 他 CPU 连接 着 的 内 





对 于 很 多 应 用 程序 ，NUMA 都 能 够 很 好 地 运作 : 
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同 的 数据 。 然 而 ， 这 
TRIER RIRE, 这 是 因为 数据 库 
其 他 应 用 程序 不 同 。MongoDB 


MongoDBIY, Jl 


访问 内 存 的 模式 与 
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需要 使 {KE 内 


CPU 的 “本 地 内 存 ” 

















存 ， 同 时 需要 CPU 能 够 访问 其 他 
。 然 而， 很 多 系统 上 默认 的 











NUMA 设 定 很 难 








CPU 倾向 于 优先 使 
则 倾向 于 优先 使 有 





满足 这 























自身 的 “本 地 内 存 ”， 而 进程 
由 同一 CPU。 这 意味 着 内 存 通常 

















“会 被 平均 地 占用 





一 小 部 分 内 存 ， 如 图 











其 100% 的 “本 地 内 存 ”， 而 其 他 处 理 器 只 使 用 
23-9 所 示 。 








结果 就 是 一 个 处 理 器 使 用 了 





























了 其 
































图 23-9 一 个 NUMA 系 统 的 内 存 占用 情况 
在 图 23-9 的 情况 下 ， 假 设 CPU1 需 要 一 些 内 存 中 没 














些 还 没有 被 读 进 
经 满 了 。 


除 出 




















度 要 比 期 望 中 

















到 了 有 效 地 利用 。 














据 ， 哪 怕 效 率 稍 
据 。 


有 的 数据 。 此 时 必须 使 用 了 
于 是 “本 地 内 存 ” 中 的 一 


得 多 ， 因 为 只 有 
MongoDB 倾 向 于 访问 更 多 的 数 











内 存 的 数据 ，1 





“本 地 内 存 ” 来 存放 这 





其 “本 地 内 存 ” 已 






































些 数 据 六 





[会 被 移 
J 存 ”中 还 





有 足够 的 空间 。 这 一 过 程 使 得 MongoDB 的 运行 速 





小 部 分 内 存 得 

















氏 ， 而 非 高 效 地 访问 一 小 部 分 数 




























































































禁用 NUMA 是 一 个 能 够 是 升 性 能 的 魔法 按钮 ， 一 
定 要 按 下 它 。 就 像 使 用 固态 磁盘 一 样 ， 禁 用 
NUMA 可 提升 所 有 事物 的 性 能 。 

如 果 可 能 的 话 ， 应 通过 BIOS 来 禁用 NUMA。 例 
如 ， 如 果 在 使 用 grub， 可 在 grub .cfg 中 添 


加 numa=off 选 项 : 
































kernel /boot/vmlinuz-2.6.38-8-generic root 

















如 果 系 统 无 法 在 BIOS 中 禁用 NUMA， 
mongod 时 使 月 





有 以 下 选项 : 





则 可 在 启动 





$ numactl --interleave=all mongod [options 





将 这 一 命令 添加 到 所 有 使 ) 





此 外 ， 禁 月 
项 认定 为 “ 


访问 一 页 内 存 时 
的 “本 地 内 存 ” 中 。 
threadA 和 
内 存 ， 则 每 次 访问 时 ， 该 页 内 存 者 
CPU 的 “本 


存 " 中 。 





也 内 存 ” 复 于 








Hzone_reclaim_modei am. 


超级 NUMA”。 








的 初始 化 














MASH 
可 把 该 选 




















该 选项 被 启 ) 








另 一 CPU 上 的 threadB 同 时 
会 被 从 一 个 
CPU 的 “本 地 内 


1 到 男 一 


LE Als ZB 





这 会 非常 、 非 

















Ja, CPU 


， 该 页 内 存 就 会 上 移动 到 此 CPU 
于 是 ， 如 果 一 个 CPU 上 的 











常 得 慢 。 


访问 一 














要 禁用 zone_rec1laim_mode， 可 运行 











$ echo @ > /proc/sys/vm/zone_reclaim_mode 





无 需 重启 mongod，zone_reclaim_mode 选 项 即 
可 生效 。 


启用 NUMA 后 ， 主 机 在 MMS 上 会 被 显示 成 黄色 ， 

如 图 23-10 所 示 。 可 通过 “LastPing”" 选 项 卡 ， 查 看 
使 其 变 成 黄色 的 具体 警告 信息 。 图 23-11 显 示 的 警 
告 信息 可 说 明 NUMA 是 否 启 用 。 
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Name 2 Type 
ip-10-62-73-192:27017 primary 





图 23-10 MMS 中 一 台 主 机 存在 启动 警告 信息 


í 
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图 23-11 有 关 NUMA 的 启动 警告 信息 
































么 MMS 二 的 主机 会 重新 显示 




































































如 果 禁 用 NUMA， 忆 
KAE. “主机 显示 为 黄色 也 可 能 是 由 于 其 他 原 
寻 。 应 同时 查看 其 他 启动 警告 信息 。) 





























23.3.2 ”更 智能 地 预 读 取 数据 








预 读 (readahead) 是 一 种 优化 手段 ， 即 操作 系统 
从 磁盘 中 读 取 比 实际 请 求 更 多 的 数据 。 这 一 优化 
的 原理 是 : 计算 机 所 处 理 的 大 部 分 工作 都 是 

续 的 ， 即 如 果 载 入 了 一 个 视频 文件 的 前 20MB 
nee 则 接 下 来 很 可 能 需要 用 到 紧 随 其 后 的 若干 
MB 内 容 。 于 是 ， 系 统 会 从 磁盘 中 读 取 比 实际 请 
求 更 多 的 内 容 ， 并 将 其 存放 到 内 存 中 ， 以 便 随 后 











































































































然而 ，MongoDB 并 非 是 典型 的 工作 负载 ， 设 置 预 
读 也 是 MongoDB 系 统 中 的 常见 问题 。MongoDB 倾 
向 于 从 磁盘 中 随机 读 取 很 多 小 块 的 数据 ， 所 以 默 
认 的 系统 设置 并 不 能 很 好 地 运作 。 如 果 预 读 内 容 
过 多 ， 内 存 中 会 逐渐 充满 MongoDB 没 有 请 求 的 内 
容 ， 迫 使 MongoDB 更 多 地 访问 磁盘。 


例如 ， 如 果 希 望 从 磁盘 中 读 取 一 个 扇 区 (512 字 
节 ) 的 内 容 ， 则 磁盘 控制 器 实际 上 可 能 会 读 取 
256 个 扇 区 ， 因 为 它 假设 我 们 接 下 来 总 会 用 到 这 




































































































































































些 内 容 。 然 而 ， 如 果 完 全 随机 地 访问 磁盘 数据 ， 
则 这 些 预 读 的 扇 区 都 会 被 浪费 挤 。 如 果 内 存 中 包 
含 了 工作 集 ， 则 其 中 的 255 个 肩 区 会 被 从 内 存 中 
移 除 ， 从 而 存放 这 些 不 会 用 到 的 内 容 。 事 实 上 
256 个 扇 区 是 
预 读 上 千 扇 区 的 内 容 。 


有 一 种 很 简单 的 方法 ， 可 供 查看 预 读 设置 
否 已 带 来 麻烦 : 检查 MongoDB 驻 留 集 (resident 
E 的 大 小 ， 并 与 系统 的 总 内 存 容量 进行 比较 。 


假设 内 存 容量 小 于 数据 大 小 ，MongoDB 的 驻 留 集 
大 小 应 稍 小 于 总 内 存 大 小 例如， 如果 有 50GB 的 
内 存 ，MongoDB 应 占用 了 至 少 46 GB) 。 如 驻 留 
集 过 小 ， 则 说 明 预 读 的 内 容 可 能 太 多 了 。 


比较 驻 留 集 和 总 内 存 大 小 这 一 方法 所 基于 的 原理 
是 : 被 预 读 的 数据 在 内 存 中 ， 而 MongoDB 没 有 请 
求 这 些 数据 ， 因 此 不 会 被 计算 在 MongoDB 的 常 驻 


内 存 大 小 中 。 


使 用 blockdev 命 令 ， 可 查看 当前 的 预 读 设 定 : 










































































































































































































































































$ sudo blockdev --report 
RO RA SSZ BSZ StartSec 


rw 256 512 4096 0 8002636 
rw 256 512 4096 2048 8002522 





256 
256 
256 
256 
256 


512 
512 
512 
512 
512 


4096 
1024 
4096 
4096 
4096 


© 200039893 

2048 9856 
194560 799958 
15818752 1999949 
54880256 197230015 























这 里 显示 J 每 个 块 设备 的 配置 。 RA 列 表示 预 读 大 








小 ， 


























可 使 
































一 设 定 值 : 
































其 单位 是 大 小 为 S12 字 节 的 扇 区 数量 。 因 
此 ， 该 系统 中 每 个 设备 的 预 读 大 小 都 设置 为 
128KB (512 27/5 





























X x256 K) 。 


以 下 命令 ， 并 通过 - -setra 选 项 来 更 改 这 











$ sudo blockdev --setra 16 /dev/sdb3 








那么 ， 
到 256 之 间 。 








预 读 大 小 设 为 多 少 为 好 呢 ? 推 荐 数值 是 16 




















预 读 大 小 也 不 应 设 得 过 小 ， 否 则 读 











取 


文档 较 小 ， 
使 文档 非常 小 ， 








个 单独 的 文档 则 需 多 次 访问 磁盘 。 如 文档 较 
大 (大 于 1MB) ， 则 应 考虑 预 读 更 多 的 内 容 。 如 
预 读 的 数值 则 应 小 一 些 ， 例 如 32。 即 












































也 不 要 将 预 读 大 小 的 值 设 为 16 以 





下 ， 这 会 导致 读 取 索引 信息 时 效率 低下 〈 索 引 桶 
Cindex bucket) 的 大 小 为 8KB) 。 








使 月 


有 RAID 时 ，RAID 控 





制 器 和 组 成 RAID 的 每 个 分 





卷 上 都 应 对 预 读 进行 设置 。 


需 重启 MongoDB 才 能 使 预 读 设 定 生 效 ， 这 一 点 看 
起 来 有 些 奇 怪 。 更 改 磁盘 属性 设置 难道 不 应 该 立 
即 对 所 有 正在 运行 的 程序 生效 吗 ? 但 可 惜 ， 
会 在 启动 时 复制 一 份 预 读 大 小 的 设置 值 ， 并 一 
按照 该 值 运作 ， 直 到 进程 停止 运行 。 














































































































23.33 ”禁用 大 内 存 页 面 

















启用 大 内 存 页 面 (hugepage) 导致 的 问题 和 预 读 
过 多 内 容 导 致 的 问题 类 似 。 不 要 启用 这 一 特性 ， 
除非 : 


。 所 有 数据 都 存放 在 内 存 中 ; 
© 不 考虑 数据 大 小 不 断 增长 最 终 超 过 内 存 容 
的 情况 。 


MongoDB 需 载 入 数量 众多 的 小 块 内 存 ， 所 以 启用 
大 页 面 会 导致 更 多 的 磁盘 IO。 


系统 以 页 面 为 单位 在 磁盘 和 内 存 间 转移 数据 。 页 
a se i ee 
。 如 果 一 台 机 器 有 很 多 GB 的 内 存 ， 那 么 页 面 
E i 很 大 ， 速 
度 就 会 更 慢 。 而 大 页 面 使 得 页 面 大 小 设 定 值 最 大 





















































四 










































































































































































可 为 256 MB 〈 在 ia64 架 


意味 着 要 














这 些 内 容 随后 又 会 
据 的 修改 刷新 到 磁盘 











将 磁盘 上 一 个 
在 内 存 中 。 MEMEA 
磁盘 中 载 入 大 块 数据 ， 只 会 更 快 地 
被 移 除 出 内 存 。 


SRE) 。 


BB 























然而 使 / 











能 全 部 存 
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此 外 ， 将 对 数 
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的 “ 脏 ” 数 据 必须 达到 几 MB， 而 非 儿 KB。 
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工 忆 ， 





X 
非 hugepages。 
+ 








而 另 一 些 版 本 则 不 
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性 征 合 已 











发 的 ， 








会 这 样 做 ， 


页 面 实际 上 是 为 了 优化 数据 库 系统 的 性 能 
所 以 有 经 验 的 数据 库 系 统管 














23.3.4 选择 一 种 磁盘 调度 算法 











人 磁盘 控 于 


的 顺序 访问 比 一 般 上 





出 器 从 操作 系统 接收 到 

















种 调度 算法 











来 决定 处 理 
变 这 一 算法 可 提高 磁盘 性 能 
作 负 载 而 言 ， 可 能 没 们 
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为 磁盘 写 入 


Windows 系 统 将 此 特性 称 为 Large Pages fi} 
一 些 版 本 的 Windows 默 认 启 用 该 特 
此 应 检查 确 
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EHR, 


节 内 容 感到 惊讶 。 然 而 ， MongoDB 对 磁盘 
的 关系 型 数据 库 要 少 得 























这 些 请 求 








求 后 ， 会 使 有 
的 顺序 。 
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对 其 他 硬 
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有 时 改 
件 和 工 
PA BUR, 最 好 的 决定 方法 








是 进行 实地 测试 。Deadline (截止 时 间 ) 调度 算 
法 和 CFQ (completely fair queueing， 完 全 公平 队 
列 ) 调度 算法 都 是 不 错 的 选择 


有 时 noop (“no-op” 的 缩写 ， 这 是 最 简单 的 调度 算 
法 ) 调度 算法 是 最 好 的 选择 。 比 如 说 处 于 虚拟 化 
环境 中 使 用 noop 调 度 算法 ， 该 调度 算法 可 基本 上 
以 最 快 的 速度 把 操作 传递 给 下 层 的 磁盘 控制 器 ， 

然后 让 真正 的 磁盘 控制 器 来 处 理 所 需 的 重新 排序 


问题 。 














































































































类 似 地 ， 在 固态 磁盘 上 ，noop 调 度 算法 通常 是 最 
好 的 选择 。 固 态 磁盘 并 不 存在 机 械 磁 盘 中 的 磁头 
位 置 问题 。 


最 后 ， 如 使 用 RAD 控 制 器 进行 缓存 ， 则 应 使 用 
noop 调 度 算法 。 组 存 的 表现 与 固态 磁盘 类 似 ， 可 
高 效 地 将 写 入 操作 分 配 到 不 同 的 磁盘 上 去 。 


可 在 启动 配置 中 使 用 - -elevator 选 项 来 更 改 调 
度 算 法 。 






































































































































A 该 选项 之 所 以 被 称 为 elevator ( 电 
Bh) ， 是 因为 调度 算法 的 功能 就 像 一 部 电梯 ， 
从 不 同 的 楼 层 〈 进 程 / 时 间 ) 接收 乘客 〈 破 盘 IO 
wok) ， 再 以 一 种 可 能 的 最 佳 方案 ， 将 之 送 至 
目的 地 。 


beara 所 有 的 调度 算法 都 能 很 好 地 运作 ， 可 
觉 不 到 太 大 的 区 别 。 













































































23.3.5 ”不 要 记录 访问 时 间 








系统 默认 记录 文件 最 后 被 访问 的 时 间 。 由 于 
MongoDB 访 问 数据 文件 十 分 频繁 ， 如 果 禁 止 记 录 
这 一 时 间 ， 则 会 得 到 性 能 上 的 提升 。 在 Linux 系 统 
中 ， 可 在 /etc/fstab 里 将 atime 更 改 为 noatime， 
以 禁止 记录 访问 时 间 。 






































/dev/sda7 /data ext4 























要 使 该 设置 更 改 生效 ， 需 先 重新 挂 载 设 备 。 
atime 在 旧 的 内 核 中 (比如 ext3) 问题 更 












































新 的 内 核 中 使 用 relatime 作 为 默认 值 ， 使 
得 更 新 不 会 那么 频繁 。 此 外 应 注意 ， 将 此 值 设 

为 noatime 可 影响 其 他 程序 使 用 分 区 ， 例 如 mutt 
或 备份 工具 。 


类 似 地 ， 在 Windows 系 统 下 应 设 
置 disablelastaccess 选 项 来 实现 相同 功能 。 运 
行 以 下 命令 完成 最 后 访问 时 间 记 录 的 禁止 


C:\> fsutil behavior set disablelastaccess 


需 重 启 使 设置 更 改 生 效 。 该 设置 可 能 影响 远程 存 
ië (Remote Storage) 服务。 不 过 由 于 该 服务 会 E 
动 移动 数据 到 其 他 磁盘 ， 所 以 本 来 也 无 需 使 用 此 
服务 。 
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23.3.6 ”修改 限制 








MongoDB 可 能 会 受到 两 个 限制 的 影响 : 
o 进程 可 建立 线程 的 数量 ; 
。 进 a 苗 述 符 (file descriptor ) 
的 数量 
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AR 与 MongoDB 服 务 器 建立 连接 时 ， 月 
这 个 连接 
此 ， 如 果 与 数据 库 建 立 了 3 
据 库 就 会 运行 3000 个 线程 〈 再 
与 客户 端 无 关 任 
MongoDB 建 立 十 几 个 甚至 几 千 个 连接 ， 有 具体 数量 
取决 于 应 用 服务 器 


动 。 




















个 线程 


来 处 理 

















大 


























如 果 客 
加 的 流量 (大 多 应 用 











Pri 


动态 




















上 发 


RA Ar 
生 的 所 有 活 











加 上 几 








个 连接 ， 数 
个 上 | FARE 



































E 务 的 线程 )。 





的 配置 。 


AH 


+H 





eA 

















HZ 











AX 


= 





保 这 些 子 进程 数 


例如 ， 如 果 
人 允许 创建 100 个 子 进程 ， 而 每 个 子 进程 又 可 创建 
10 个 线程 连接 到 MongoDB， 那 么 最 多 就 可 
20x 10720 00073 


上 万 的 线程 可 
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| 建 更 多 的 子 进 
务 器 都 会 这 么 做 ) ， 应 确 
保持 在 MongoDB 的 限制 以 内 。 
服务 器 ， 其 中 
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色 新 的 连接 。 


是，MongoDB 能 够 打开 
每 个 连 入 和 连 出 的 连接 都 要 


果 进 程 
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符 ， 如 果 
ARE, M 
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户 端 连 接 的 数量 真有 
1 会 打开 20 000 个 文件 描 
这 也 是 MongoDB 所 允许 的 最 大 数 








与 很 多 分 片 建立 连 























接 。 当 客 








户 端 连 接 到 mongos 并 发 起 请 求 





时 ， mongos | 向 所 有 



































所 需 的 分 片 建立 连接 ， 以 完成 请 求 。 


集群 中 有 100 个 分 片 ， 而 客 
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据 ，mongos 就 必须 


计 100 个 连接 。 这 会 
长 ， 可 依照 之 前 的 例子 想象 一 下 。 
服务 器 向 mongos 进 程 建立 了 
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是 说 对 所 有 分 片 建立 的 
连 入 连接 x100 个 分 片 =10 000 个 ! 
上 的 查询 都 没有 特定 目标 ， 这 种 设 
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例子 一 样 ) 。 如 果 限 制 值 过 低 ，“LastPing" 选 项 
卡 中 会 出 现 类 似 图 23-12 中 所 示 的 信息 。 








as a low ulimit setting configured. For more information, see the MongoDB docs 
{ 
"port": 27017, 





图 23-12 ”MMS 中 有 关 限 制 值 过 低 的 警告 信息 


即使 不 使 用 分 片 ， 应 用 程序 建立 的 连接 数 也 很 
少 ， 也 应 至 少将 软 硬 限制 均 增 至 4096。 这 样 ， 
MongoDB 就 不 再 会 为 此 发 出 警告 ， 也 给 了 我 们 一 
些 喘息 空间 ， 有 备 无 患 。 


23.4 网 络 配置 


本 节 我 们 将 学 习 哪些 服务 器 间 应 建立 连接 。 通 党 

情况 下 ， 出 于 网 络 安全 (和 灵敏 度 ) 考虑 ， 我 们 

会 希望 限制 MongoDB 服 务 器 的 网 络 连接 。 注 意 ， 

多 服务 器 MongoDB 的 部 署 应 能 够 处 理 网 络 被 隔断 

但 并 不 推荐 将 其 作为 一 般 情 况 下 的 部 署 
Az 


在 独立 服务 器 上 ， 客 户 端 须 能 够 与 nongod 建 立 连 
接 。 


副本 集成 员 必 须 能 够 连接 到 其 他 各 成 员 。 客 户 端 

































































































































































必须 能 够 连接 到 所 有 可 见 
网 络 配 置 的 不 同 ， 成 员 可 外 
接 ， 所 以 应 允许 mongods 建 并 到 EE 
分 片 要 稍微 复杂 一 些 。 


。Imongos 服 务 器 ; 
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以 下 


连接 要 求 可 概括 为 以 下 三 点 : 
。 客户 端 必须 能 够 连接 到 一 


e mongos 服 务 器 必须 能 


服务 器 ; 


分 片 必 
AF o 


须 能 够 连接 到 
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其 他 分 
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四 种 组 件 组 成 : 





个 mongos 服 务 器 ; 
到 众 分 片 和 配置 


























片 和 配置 服务 




















显示 了 完整 的 连接 需求 。 
分 片 连接 
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SHAE anges |a EEBS] 。 客户 
mongos 不 需要 要 不 需要 需要 

a 需要 需要 | 不 需要 不 推荐 

配置 服务 器 | 需要 需要 | 不 需要 不 推荐 
apm lame | EE lame | gMoeB% 


























表格 中 有 三 种 可 能 的 值 。 


。“ 需 要 ”表示 二 者 间 应 建立 连接 ， 以 保证 分 片 
正常 运行 。 若 由 于 网 络 问题 导致 连接 中 断 的 
话 ，MongoDB 会 尝试 进行 平稳 退化 ， 以 尽 可 
能 地 解决 问题 ， 但 不 应 故意 做 如 此 配置 。 


。“ 不 需要 ”表示 二 者 不 会 在 指定 方向 进行 通 
信 ， 也 就 无 需 建立 连接 。 


0 “不 推荐 "表示 二 者 间 不 会 进行 通信 ， 但 用 户 
的 错误 操作 则 会 促使 相互 通信 的 完成 。 例 
如 ， 推 荐 做 法 是 限制 客户 端 上 只 与 mongos 建 立 
连接 ， 而 不 与 分 片 建立 连接 ， 这 样 客 户 端 就 
不 会 在 无 意 中 直 接 向 分 片 请 求 内 容 。 类 似 
地 ， 客 户 端 应 无 法 直接 访问 配置 服务 器 ， 以 











































































































































































































防 意外 更 改 配置 数据 。 
注意 ，mongos 进 程 和 分 片 会 主动 与 配置 服务 器 进 
ee eee 其 
或 是 个 配置 服务 器 建立 连接 。 


分 片 在 进行 迁移 时 必须 进行 通信 ， 因 为 可 直接 连 
接 到 其 他 分 片 以 传输 数据 。 


如 前 所 述 ， 组 成 分 片 的 副本 集成 员 应 能 够 与 
身 建立 连接 。 


23.5 系统 管理 


本 节 我 们 将 学 习 一 些 在 部 署 服 务 器 前 应 注意 的 常 
见 问题 。 
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23.5.1 ”时 钟 同步 





一 般 来 讲 ， 各 系统 间 的 时 钟 误 AN 秒 是 最 
为 安全 的 。 副 本 集 应 能 够 处 理 几 乎 所 有 的 时 钟 偏 
移 (clock skew) 。 分 片 则 外 2 够 处 理 部 分 时 钟 
扁 移 《如 偏 移 超过 几 分 钟 ， 日 志 中 会 出 现 警 告 信 
息 ) ， 但 最 好 将 偏 移 降 至 最 小 。 使 时 钟 保持 同 

步 ， 也 使 得 查看 日 志 内 容 变 得 更 加 方便 。 











































































































为 保持 时 钟 同步 ， 在 Windows 系 统 中 可 使 用 
w32tm 工 具 ， 而 在 Linux 系 统 中 则 可 使 用 ntp 后 台 进 


















































23.5.2 OOM killer 








在 极 偶然 的 情况 下 ，MongoDB 会 因 分 配 过 多 内 存 
而 被 OOM Killer (Out of Memory killer， 内 存 溢 昌 
AF) 上 上。 尤其 是 在 建立 索引 时 发 生 ， 这 也 是 
MongoDB 的 常 驻 内 存 会 给 系统 造成 压力 的 少 有 情 
况 之 一 。 


如 果 MongoDB 进 程 突然 被 终止 ， 而 日 志 中 又 没有 
出 现 错 误 或 退出 信息 ， 则 应 检查 
/var/log/messages (或 内 核 记录 这 些 内 容 的 其 他 位 


置 ) ， 查 看 是 否 存在 关于 终止 mongod 进程 的 信 





Co 





























































































































如 果 内 核 因 为 过 度 使 用 内 存 而 终止 了 MongoDB 进 
程 ， 则 应 在 内 核 日 志 中 看 到 如 下 内 容 : 


kernel: Killed process 2771 (mongod) 
kernel: init invoked oom-killer: gfp_mask= 



























































如 果 开 启 了 日 志 系 统 (journaling) ， 此 时 重启 
mongod 进 程 即 可 。 如 没有 开启 日 志 系 统 ， 则 应 恢 









































复 备份 ， 或 重新 与 副本 进行 同步 。 


当 系 统 没有 交换 空间 ， 并 且 可 用 内 存 开始 减少 

IN, OOM killer 就 会 变 得 尤为 敏感 ， 因 此 为 避免 
麻烦 ， 不 妨 配置 适当 的 交换 空间 。MongoDB 应 不 
会 用 到 该 交换 空间 ， 但 这 可 让 OOM Killer 放 松下 
来 。 


如 果 OOM killer 终 止 了 一 个 mongos 进 程 ， 重 启 它 
即 可 。 








































































































23.5.3 ”关闭 定期 任务 





检查 是 否 存在 计划 任务 或 后 台 进 程 ， 它 们 可 能 
期 被 激活 并 消耗 系统 资源 ， 比 如 软件 包 管理 器 的 
自动 更 新 。 这 些 程序 被 激活 后 会 消耗 大 量 的 内 存 
和 CPU 资源 ， 然 后 又 消失 不 见 。 我 们 不 会 希望 在 
生产 服务 器 上 见 到 这 些 东 西 。 

























































































附录 A 安装 MongoDB 


MongoDB 的 二 进 制 文件 可 用 于 Linux、Mac OS 
X、Windows 和 Solaris 系 统 。 这 意味 着 在 大 部 分 平 
台中 ， 均 可 从 http://www.mongodb.org/downloads 
下 载 一 份 代码 ， 解 压 并 运行 二 进 制 文件 。 


MongoDB 的 运行 需要 一 个 目录 来 写 入 数据 库 文 

件 ， 并 需要 一 个 端口 来 监听 连接 。 本 节 我 们 将 学 
习 MongoDB 在 Windows 和 非 Windows (Linux、 
Max、Solaris) 两 种 操作 系统 上 的 安装 过 程 。 


提 及 “安装 MongoDB” 时 ， 我 们 通常 指 的 是 对 
mongod 进 行 配置 。mongod 是 核心 数据 库 服务 器 ， 
可 作为 独立 服务 器 或 副本 集成 员 。 大 多 时 候 ， 
mongod 是 我 们 使 用 的 MongoDB 进 程 。 















































































































































A1 选择 一 个 版 本 

MongoDB 所 使 用 的 版 本 管理 相当 简单 : 偶数 号 为 
稳定 版 ， 奇 数 号 为 开发 版 。 例 如 ， 以 2.4 开 头 的 版 
本 都 是 稳定 版 ， 如 2.4.0、2.4.1、 和 2.4.15。 以 2.5 
开头 的 则 是 开发 版 ， 如 2.5.0、2.5.2 和 2.5.10。 接 
下 来 我 们 以 2.4 和 2.5 版 本 为 例 ， 来 演示 版 本 变化 
的 时 间 线 。 





1. MongoDB2.4.0 发 布 。 这 是 一 项 重大 发 布 
(major release) , 
(changelog) ; 


有 大 量 的 更 新 





2. 开发 者 在 开 





发 布 的 稳定 版 本 ) 后 ， 


能 包含 一 两 个 额外 的 特性 ， 





漏洞 。 








台 着 手 














日 志 





开发 2.6 版 本 〈 下 一 个 重大 


发 布 了 2.5.0 版 本 。 这 
是 新 的 开发 分 支 ， 与 2.4.0 版 本 很 相似 ， 但 可 





3. iA 


2.5.1 和 2.5.2 等 版 本 。 


环境 中 。 





2.4.1、 








开发 者 继续 增加 新 
这 些 版 本 不 应 | 











的 特性 

















可 能 存在 一 些 





， 他 们 发 布 了 




















] 于 生产 














. 一 些小 的 漏洞 修复 可 能 用 于 旧 

(这 一 做 法 称 为 backport)〉， 
2.4.2 等 版 本 。 
做 法 。 稳 定 版 本 中 很 少 ] 
只 进行 漏洞 修复 。 
































兽 加 


新 





的 2.4 分 支 上 


随后 发 布 了 
开发 者 会 慎重 考虑 这 一 

















Pr 


rf 





的 特性 


， 通 


5. 在 2.6.0 达 到 所 有 重大 既定 目 


2.5.7 (或 任何 最 

















标 后 ， 版 本 


新 的 开发 版 本 ) 就 会 变 为 



























































2.0.0-Tc0 。 

6. 在 对 2.6.0-rc0 进 行 大 量 测试 后 ， 一 般 会 发 现 
一 些 需要 修复 的 小 漏洞 。 开 发 者 修复 这 些 漏 
洞 并 发 布 2.6.0-rc1 版 本 。 

7. 开发 者 重复 第 6 步 直 到 没有 新 的 明显 漏洞 ， 
然后 2.6.0-rc2 〈 或 任何 此 时 的 最 新 版 本 ) 会 
重 命名 为 2.6.0。 

8. 从 第 1 步 重新 开始 ， 此 时 所 有 版 本 号 增加 
0.2。 

在 MongoDB 的 漏洞 追踪 系统 





(https://jira.mongodb.org/secure/Dashboard.jspa) 








上 ， 存 在 着 核心 服务 器 路 线 图 。 





可 得 知 下 一 个 稳定 版 本 的 发 布 时 间 。 


若 在 生产 环境 中 











运行 ， 则 应 使 用 








划 在 生产 环境 中 





(mailing list) 或 耻 C 中 询问 开 











使 用 开发 版 本 ， 














如 果 刚 刚 开 始 一 个 项 目的 开发 ， 
许 是 更 好 的 选择 。 








带 有 所 使 用 特性 

















在 将 其 部 署 至 


查看 该 路 线 图 ， 








稳定 版 本 。 如 计 
应 先 在 邮件 列表 




















使 用 开发 版 本 也 
生产 环境 中 时 ， 





























的 稳定 版 本 可 能 





已 经 发 布 了 


CMongoDB 尽 量 做 到 每 6 个 月 定 版 


本 ) 。 


然而 ， 可 能 





会 遇 到 一 





些 系统 漏洞 ， 这 会 























j 户 感到 非常 失望 ， 








大 

















此 必须 对 此 进 





行 权衡 


A.2 在 Windows 系 统 中 安装 


要 在 Windows 系 统 中 安装 MongoDB， 应 在 

MongoDB 下 载 页 中 下 载 适 用 于 Windows 的 zip 压 缩 
包 。 参 见 上 一 节 内 容 选 择 合适 的 版 本 。 发 行 版 本 
分 为 Windows32 位 和 64 位 两 种 ， 选 择 与 系统 相符 
的 即 可 。 点 击 链接 下 载 .zi 文件 并 解压 。 


现在 需要 建立 一 个 目录 ， 以 便 MongoDB 能 够 写 入 
数据 库 文件 。MongoDB 默 认 尝试 使 用 当前 驱动 器 
的 \data\db 目 录 作 为 其 数据 目录 〔 例 如 如 在 C: 
下 运行 Rongod， 则 会 使 用 C:\data\db) 。 
件 系统 中 的 任何 位 置 建立 这 一 目录 或 其 他 空 
录 。 如 不 使 用 \data\db 目 录 ， D 
时 指定 路 径 ， 有 具体 做 法 马上 就 会 讲 到 。 


既然 已 经 有 了 数据 目录 ， 则 应 打开 命令 提示 符 
(cmd.exe ) 。 定 位 到 解压 后 的 MongoDB 二 进 仙 
文件 所 在 目录 ， 然 后 运行 : 



















































































































































































































































































i 














$ bin\mongod.exe 























如 使 用 C:\data\db 以 外 的 目录 ， 需 使 用 --dbpath 
参数 指定 其 位 置 : 


$ bin\mongod.exe --dbpath C:\Documents and 
























































第 20 章 介绍 了 更 多 的 常用 选项 。 也 可 运 
4{7mongod.exe --help 来 查看 所 有 选项 。 


作为 一 个 服务 安装 


MongoDB 也 可 作为 Windows 的 一 个 服务 
(service) 安装 。 只 需 以 全 路 径 运 行 ， 避 免 空 
格 ， 并 使 用 - -instal1 选 项 ， 即 可 完成 安装 。 例 
如 : 


















































$ C:\mongodb-windows-32bit-1.6.0\bin\mongo 
--dbpath "\"C:\Documents and Setting 















































之 后 就 可 以 使 用 控制 面板 来 启动 和 停止 MongoDB 
服务 。 

















A.3 在 POSIX 系 统 (Linux. Mac 
OS X, Solaris) 中 安装 





依据 A.1 节 的 内 容 ， 选 择 MongoDB 的 版 本 。 前 往 
MongoDB 下 载 页 ， 选 择 适 合 操作 系统 的 版 本 。 





Va 
“a 




















a 
we, 
4 如 使 用 的 是 Mac 系 统 ， 应 检查 系统 


是 32 位 的 还 是 64 位 的 。Mac 对 于 版 本 的 要 求 十 
分 严格 ， 如 版 本 选择 错误 ， 则 会 拒绝 启动 
MongoDB, 并 给 出 令 人 不 解 的 错误 信息 。 可 点 
击 左 上 角 的 苹果 标志 ， 选 择 关 于 该 台 

Mac (About This Mac) 选项 ， 检 查 操 作 系 统 版 
本 。 





















































必须 创建 一 个 目录 以 便 数据 库 写 入 文件 。 数 据 库 
会 默认 使 用 /data/db 目 录 ， 也 可 指定 其 他 目录 


如 建立 了 默认 目录 ， 则 应 确保 拥有 正确 的 写 权 
限 。 可 通过 如 下 命令 ， 创 建 目录 并 设置 权限 : 


$ mkdir -p /data/db 
$ chown -R $USER: $USER /data/db 




































































如 有 必要 ， 可 使 用 mkdir -p 命 令 ， 建 立 指定 
录 及 其 所 有 父 目录 〔 例 如， 如果/data 目 录 不 存 
在 ， 则 会 先 建立 /data 目 录 ， 然 后 再 建立 /data/db 
目录 ) 。 使 用 chown 命 令 ， 可 改变 /data/db 的 所 有 
权 ， 以 便 实现 用 户 对 其 的 写 入 。 当 然 ， 也 可 在 
home 文 件 夹 中 建立 一 个 目录 ， 并 在 启动 数据 库 时 
肯定 其 作为 MongoDB 的 数据 目录 ， 从 而 避 开 权限 


问题 。 









































































































































将 从 http:/www.mongodb.org 下 载 的 .tar.gz 文 件 解 
压缩 。 





$ tar zxf mongodb-linux-i686-1.6.0.tar.gz 
$ cd mongodb-1linux-i686-1.6.0 











现在 可 启动 数据 库 : 














$ bin/mongod 

















如 果 想 改变 数据 库 的 位 置 ， 可 使 用 - -dbpath 先 
项 指定 位 置 ， 




















$ bin/mongod --dbpath ~/db 











o 常用 的 选项 内 容 ， 可 参见 第 20 章 中 的 内 
。 也 可 运行 ongod - -help 来 查看 所 有 选项 。 




















使 用 包 管 理 


























器 安装 























这 些 系统 中 存在 很 多 包 管 理 器 ， 可 用 于 MongoDB 


的 安装 。 如 选择 使 用 
RedHat、Debian 和 Ubuntu 系统 提供 的 官方 安装 
其 他 系统 提供 的 非 官 方 安装 包 。 如 选择 
使 用 非 官 方 版 本 ， 应 确保 使 用 的 版 本 相对 较 新 。 


包 ， 以 及 ] 












































包 管 理 器 进行 安装 ， 可 选择 



























































OS X 系 统 提 供 有 Homebre 和 MacPorts 两 种 非 官 方 
安装 包 。 如 选择 MacPorts 版 本 ， 请 注意 : 它 会 耗 


时 若干 小 时 编译 所 有 的 Boost 库 ， 这 是 安装 























MongoDB 的 必 备 前 提 。 开 启 下 载 后 就 去 睡觉 吧 。 





























无 论 使 





去 找 它 








哪 种 包 管理 

















志 (log) 文件 位 置 ， 而 不 要 等 到 出 现 问 题 后 才 





器 ， 痢 应 先 明确 MongoDB 的 











门 。 确 保 在 发 生 任何 可 能 的 问题 前 ， 日 志 











已 保存 完好 。 





附录 B 深入 MongoDB 


高 效 地 使 用 MongoDB， 并 不 需要 对 MongoDB 的 内 
部 机 理 有 深入 的 了 解 。 但 相关 工具 的 开发 者 、 代 
人 码 贡 献 者 ， 或 单纯 想 知 其 所 以 然 的 人 ， 可 能 会 对 
此 感 兴趣 。 本 附录 包括 一 些 相关 的 基本 内 容 。 可 
在 https://github.com/mongodb/mongo 处 得 到 
MongoDB 的 源 代码 。 






























































B.1 BSON 


MongoDB 中 的 文档 是 一 个 抽象 概念 ， 文 档 具体 的 
存在 形式 取决 于 使 用 的 驱动 程序 和 编程 语言 。 基 
为 文档 被 广泛 应 用 于 MongoDB 的 通讯 ， 因 此 还 需 
要 一 种 由 MongoDB 生 态 系统 里 所 有 驱动 程序 、 工 
具 和 进程 共享 的 文档 。 这 种 文档 格式 叫做 Binary 
JSON (二 进 制 JSON) ， 或 称 BSON 〈 没 人 知道 其 
中 的 J 去 哪 了 ) 。 


BSON 是 一 种 轻 量 的 二 进 制 格式 ， 可 用 一 串 字 节 
来 描述 任何 MongoDB 文 档 。 数 据 库 能 够 理解 
BSON 格 式 ，BSON 也 是 文档 存放 于 磁盘 中 的 格 
式 。 


驱动 程序 在 使 用 文档 进行 插入 、 查 询 或 其 他 操作 
时 ， 会 先 将 文档 编码 成 BSON 格 式 ， 然 后 发 送 给 
服务 器 。 同 样 地 ， 服 务 器 将 文档 返回 给 客户 端 

时 ， 也 是 以 BSON 格 式 进行 的 。 驱 动 程序 会 先 对 
此 BSON 数 据 进行 解码 ， 然 后 再 发 送 给 客户 端 。 


BSON 格 式 主 要 有 以 下 三 大 优点 。 
。 高 效 


BSON 可 高 效 描述 数据 ， 而 无 需 占 用 过 多 额 
外 空间 。 在 最 坏 的 情况 下 ， 其 效率 比 JSON 低 












































































































































































































































































































































一 点 。 而 在 最 好 的 情况 下 〈 如 存储 二 进 制 信 
息 或 大 数据 时 ) ， 其 效率 要 高 出 JSON 很 多 。 


。 可 遍历 性 
在 有 些 情况 下 ，BSON 以 空间 效率 为 代价 ， 
使 自身 更 容易 被 遍历 。 例 如 ， 字 符 毕 值 会 被 
加 上 一 个 前 级 用 以 表示 长 度 ， 而 不 是 依赖 于 
中 止 符号 来 判断 字符 的 末尾 。 这 一 特性 在 
MongoDB 服 务 器 需 对 文档 进行 内 省 
introspect) 时 十 分 实用 。 


。 高 性 能 
最 后 ，BSON 可 快速 进行 编码 和 解码 。 它 使 
月 类 C 类 型 表示 ， 这 在 大 部 分 编程 语言 中 可 
快速 运作 。 













































































y 


























如 需 了 解 BSON 的 详细 规范 ， 请 查 
看 http://www.bsonspec.org。 











B.2 线路 协议 


驱动 程序 使 用 一 个 轻 量 的 TCP/IP 线 路 协议 (wire 
protocol) 来 访 问 MongoDB 服 务 器 。 可 在 
MongoDB 的 wiki 页 面 找到 该 协议 的 文档 ， 但 其 基 
fae ever EN Les 例 
如 ， 一 个 表示 插入 文档 的 消息 包含 了 20 字 节 的 头 
an H 人 RA 
以 及 消息 的 长 度 ) 、 被 插入 的 集合 名 称 和 插入 的 
BSON 文 档 列表 。 

























































































B.3 数据 文件 


在 MongoDB 数 据 目 录 〈 默 认 下 是 /data/db/) "F, 

















每 个 数据 库 都 对 应 若干 文件 。 每 个 数据 库 都 拥有 





一 个 单独 的 扩展 名 为 .ns 的 文件 和 几 个 数据 文件 ， 





这 些 数据 文件 以 单调 

















增长 的 数字 为 扩展 名 。 于 


是 ， 名 为 foo 的 数据 库 会 被 存储 在 foo.ns、foo.0、 
foo.1、foo.2 等 文件 中 。 





每 个 数据 文件 的 大 小 是 前 一 个 文件 大 小 的 二 倍 ， 









































使 用 连续 的 磁盘 空间 








直到 达到 最 大 值 2 GB。 这 一 特性 使 得 较 小 的 数据 
库 不 会 浪费 过 多 的 磁盘 空间 ， 而 较 大 的 数据 库 可 














o 








MongoDB 也 会 预 分 配 数据 文件 ， 以 保证 性 能 稳定 
(使 用 - -noprealloc 选 项 可 关闭 这 一 特性 ) 。 

















预 分 配 在 后 台 运 行 。 















































数据 文件 一 旦 被 填 满 ， 就 会 


开始 进行 预 分 配 。 这 意味 着 MongoDB 服 务 器 总 会 








为 每 个 数据 库 维护 一 
避免 文件 分 配 失 败 。 











个 额外 的 空白 数据 文件 ， 以 





B.4 命名 空间 与 区 段 


在 数据 文件 中 ， 数 据 库 被 按照 命名 空间 
(namespace) 进行 组 织 ， 每 个 命名 空间 中 存放 有 
特定 集合 的 数据 。 集 合 中 的 文档 和 索引 都 拥有 自 
己 的 命名 空间 。 命 名 空间 的 元 信息 (metadata) 
存放 在 数据 库 的 .ns 文件 中 。 


每 个 命名 空间 中 的 数据 在 磁盘 上 会 被 分 为 几 组 数 
据 文 件 ， 即 区 段 Cextent) 。 图 B-1 中 名 为 foo 的 数 
据 库 有 三 个 数据 文件 ， 其 中 第 三 个 是 预 分 配 的 空 
文件 。 而 前 两 个 数据 文件 ， 则 分 成 了 分 属于 不 同 


命名 空间 的 区 段 。 



























































































































































foo.1 


i foo.test 


00000000000 | foo.bar 


00000000000 


E foo.baz 


00000000000 | foo.Sfreelist 
00000000000 0000 moez 


foo.2 Oooo) 
00000000000 
00000000000 
00000000000 





图 B-1 命名 空间 与 区 段 


图 B-1 中 显示 了 几 点 有 关 命 名 空间 和 区 段 的 有 趣 





内 容 。 每 个 命名 空间 可 拥有 几 个 不 





同 的 区 段 ， 这 


儿 个 区 段 在 磁盘 上 不 见得 一 定 是 连续 的 。 就 像 数 


据 库 的 数据 文件 一 样 ， 为 命名 空间 新 分 配 的 区 





段 ， 其 大 小 也 会 不 断 增长 。 命 名 空 
的 空间 ， 又 要 尽量 保证 其 在 磁盘 上 








间 会 浪费 一 定 
占有 一 个 连续 





的 区 域 ， 这 样 做 是 为 了 在 二 者 之 间 取 得 平衡 。 图 





中 还 出 现 了 一 个 特殊 的 命名 空间 $freelist， 用 

















于 跟踪 记录 不 再 使 用 的 区 段 〈 如 被 删除 的 集合 或 
索引 所 使 用 的 区 段 ) 。 命 名 空间 在 分 配 一 个 新 区 
段 时 ， 会 先 搜索 空闲 列表 ， 碍 看 是 否 存 在 合适 大 
小 的 区 段 。 





























B.5 内 存 映 射 存储 引擎 


MongoDB 默 认 的 《也 是 此 书写 作 时 唯一 支持 的 ) 
存储 引擎 ， 是 一 个 内 存 映 射 引擎 。 服 务 器 启动 

时 ， 其 内 存 对 所 有 数据 文件 进行 映射 。 接 下 来 就 
由 操作 系统 负责 将 数据 刷新 到 磁盘 ， 以 及 管理 内 
oe 该 存储 引擎 有 以 下 几 个 重要 
寺 性 : 


。 MongoDB 中 负责 管理 内 存 的 代码 数量 少 
因为 大 部 分 相关 工作 已 交 由 操作 系统 解 
MongoDB 服 务 器 进程 占用 的 虚拟 内 存 通常 很 
大 ， 超 过 整个 数据 集 的 大 小 。 这 是 可 以 接受 
ay 因为 操作 系统 会 处 理 内 存 中 的 常 驻 内 存 
小 ; 
32 位 的 MongoDB 服务 器 在 使 用 内 存 方面 有 所 
限制 ， 每 个 mongod 最 多 只 能 使 用 约 2 GB 内 
存 。 这 是 因为 所 有 的 数据 都 必须 是 在 32 位 下 
可 寻 址 的 。 
。 本 书 由 “ 行 行 ? 整 理 ， 如 果 你 不 知道 读 什么 书 
或 者 想 获得 更 多 免费 电子 书 请 加 小 编 微 信 或 
QQ: 491256034 小 编 也 和 结交 一 些 喜 欢 读书 
的 朋友 或 者 关注 小 编 个 人 微 信 公众 号 id 
d716-716 为 了 方便 书 友 朋友 找 书 和 看 书 ， 小 


















































































































































































































































































































































编 自 己 做 了 一 个 电子 书 下 载 网 站 ， 网 址 : 
www.ireadweek.com QQ 群 : 550338315 





术语 
这 些 都 是 比较 确定 的 术语 名 称 ， 如 果 其 他 章节 与 
这 里 不 一 致 ， 以 这 个 文件 中 的 术语 为 准 。 


Secondary Index => 二 级 索引 
Range Query => 范围 查询 
Aggregation => 聚合 

Geospatial Index => 地 理 空 间 索 引 
Document-Oriented => 面向 文档 的 
row => íF 

document => 文档 

Predefined Schema => 预定 义 模式 
Key => 键 

Value => 值 

Scale Up => 纵向 扩展 
Scale Out => 横向 扩展 

Aggregation Pipeline => 聚合 管道 
Pipeline => 管道 

session => # 非 常 通 用 的 术语 ， 不 译 
File Storage => 文件 存储 

Join => 联接 

Multirow Transaction => 多 行事 务 
Dynamic Padding => 动态 填充 
Cache => RIF 






















































































Relational Database Management System => 关 
系 型 数据 库 管 理 系 统 

Dynamic Schema => 动态 模式 

disk seek => 人 磁盘 寻 道 

query document => 查询 文档 
stdout => 标准 输出 
acknowledged wirte => 应 答 式 写 入 
unacknowledged wirte => 非 应 答 式 写 入 






























































如 果 你 不 知道 读 什 么 书 ， 


就 关注 这 个 微 信号 。 


公众 号 ID: d716-716 


小 编 : 行 行 : 微 信号 : 491256034 


为 了 方便 书 友 朋友 找 书 和 看 书 ， 小 编 自 己 做 了 
个 电子 书 下 载 网 站 ， 网 址 : www.ireadweek.com 
QQ 群 : 550338315 小 编 也 和 结交 一 些 喜 欢 读书 的 
朋友 


“幸福 的 味道 "已 提供 120 个 不 同类 型 的 书 六 



























































[EK 

















Æ 





1、 252A — ne BEAN 25 A 


2、20 世 纪 最 优秀 的 100 部 中 文 小 说 



































3、 10 部 豆 为 高 评分 的 温情 治愈 系 小 说 


有 生 之 年 ， 你 一 定 要 看 的 25 部 外 国 纯 文学 名 
































5、 有生之年 ， 你 一 定 要 看 的 20 部 中 国 现 当代 名 

















6、 美国 亚马逊 编辑 推荐 的 一 生 必 读 书 单 100 本 
7、 30 个 领域 30 本 不 容错 过 的 入 门 书 
8、 这 20 本 书 ， 是 各 领域 的 茵 峰之 作 

9、 这 7 本 书 ， 教 你 如 何 高 效 读书 

10、 80 万 书 虫 力荐 的 “给 五 星 都 不 够 ”的 30 本 : 



































关注 “幸福 的 味道 ” 微 信 公众 号 ， 即 可 查看 对 应 书 
单 
































如 果 你 不 知道 读 什 么 书 ， 就 关注 这 个 微 信号 。 


